Loopback test on a single CAN port

[@rcs]

Hi,

I have a simple query. I am not able to reason it out well.

I want to know whether it is possible to do a loopback test on a single CAN port.

1. Ideally the answer should be know as CAN as such is a half duplex protocol. So the transceiver can only transmit or receive at a single point of time.

2.  But if I look carefully at how CAN operates. 2 transmitters trying to transmit at the same time, transmit their ID bits and listen to the ones being transmitted at the same time. Whenever the CAN transmitter sees that there is a dominant being transmitted at the same time it is transmitting recessive, it stops transmitting losing arbitration. This means the transceivers should be transmitting and receiving at the same time.

3. The CAN node keeps on transmitting unless and until it receives an acknowledgement.

4. So, if I create 2 sessions for the same interface, one as a Frame Input and the other as a Frame output. Transmit the frame first without any other node in the network. The transmitter won't receive an acknowledgement and keep on transmitting. Whereas the Frame Read API should read the frames being transmitted. Will it happen in this way or the Frame Out will wait for the acknowledgement, wait for the timeout and if it times out, it will stop transmitting? My instinct says it will stop transmitting and I tried to verify that through the hardware as well. But I am not sure if I am doing everything correctly.

So, let me put the question again: If I have a single CAN port with no other node on the bus. The CAN hardware has not cable connected. I try writing frame over the frame and then try to read it. Will the loopback test work?

[Hooovahh]

Okay a couple of things.  So you are right that the CAN spec states that a frame will be sent, and if no device on the bus responds, then the message will be sent over and over again until an Ack is seen from any node on the bus.

So if you have one CAN port plugged into nothing and send a CAN frame, you can put a scope on the line and see the traffic continue to be sent out over and over again.  

If you have a Frame Out on CAN0 and a Frame In on CAN1, and wire from one to the other, then CAN1 will send the Ack back when the tranceifer sees the message.  This is automatic and happens on the tranceiver level.  So in this case sending a frame on CAN0 will only be sent once, because CAN1 will send the Ack (assuming CAN1 actually gets the message)

There are two other exceptions to this setup.  You can configure a Frame Out to perform a Single Shot transmit, and regardless if you see an Ack the frame will only go out once.  The issue with this is the message might actually be lost due to noise or message collision, and your hardware won't retransmit it.  This makes the bus less robust.

Another interesting option is the Frame In can be configured to not send the Ack when it sees the message, but still perform the read.  This way if you send a frame out on CAN0, you can then read the frame on CAN1, but CAN0 will think no node has seen the message, and it will send it over and over again until a node on the bus sends the Ack.

[@rcs]

Thanks for replying Hooovahh !!

You've explained things well. But I am confused on the fact that. If the message  is transmitted from the tranceiver and there is no receiver on the other end(single node on the bus), can we configure the read session to read the same message simultaneously. Basically the question is that whether or not there is a buffer on the CAN controller which allows reading of the same message as being transmitted? Can we have a loopback test performed on a single CAN port without having any other device on the CAN bus.

Thanks Again !

[Hooovahh]

I'm not fully understanding you so sorry if this isn't what you are talking about.  When you write a frame of CAN there is an option to Echo it.  What this will do is cause the CAN read on that port to return the written CAN message.  I am unsure if this is a physical loop back in the hardware, a software one in the XNet driver, or one built into the transceiver.  If you were to use this I don't know what a retransmitted message would look like, you may see the re-transmitted message or not, depending on how it was implemented.  I'd test it but again you can combine this with the single shot transmission and only one frame will be sent even if no Ack is seen.  I think the echo feature maybe limited to the frame API and not signal, I'm pretty sure single shot is a function of the interface so would work on both APIs.

[jaime_c]

Hello Hooovahh,

Do you know if there's a way to stop the unacknowledged frame once it is being transmitted over and over again?

I have a part that will only wake up (power up) on a given payload from a given frame and I need to test that feature.  The problem is once the part is in sleep mode, it doesn't acknowledge frames and my CAN interface is stuck trying to transmit a message that won't wake the part.

[Hooovahh]

If a frame is not setup to be single shot, and it goes unachnowledged, I believe it will continue to be sent until the interface is reinitialized.  So you might get away with closing and reopening the session.  Other than that I don't know of a way to stop it once it has started.  As I said maybe enabling Single Shot is the method you need, as long as your network is robust and dropped frames are rare.

[jaime_c]

Thanks for the quick reply, Hooovahh.  I didn't know Single Shot was an option until today  so I'll have to think about that.  My biggest concern there would be message collision and the effect it would have on message authentication counters being used on the network.

I tried stopping the session when the frame transmission times out, but it looks like the hardware still continues to transmit the frame until the application ends.

Luckily I did some work to create a state machine in my app that should make reinitializing the interface simpler and more robust.