Hi, I'm preparing a end of production test for a board. The test will be semi automatic, there will be a guy that push some buttons and turn some poti. On the board I have rs232 an CAN communication. For rs232 it's easy, I make a loopback after the tranceiver and just check that the yte I receive is the same that I sent.
But for CAN? it's possible to do something similar? The loopback function in MSCAN module is useless because I need to check that the tranceiver and the connector are ok.
You should be able to test that the transceiver is electrically functioning with a termination plug. To test sending and receiving properly requires a second node.
If your CAN software allows you to access statistics like numbers of collisions, retries, failures, etc. then with a single node on a terminated line, you should see zero collisions/retries/failures from transmissions. Then you can *carefully* "jam" the line by applying a bias voltage and try sending again - with the jamming on you should see collisions, retries and failures.
But that only shows that the transceiver is alive. To test that it is not mangling bits you need a conversation with a second node.
For any meaningful testing, you need an other CAN device (in fact any CAN device with correct speed).
For proper operation on a CAN bus system, each node is supposed to receive any frames on the bus, perform CRC check and if OK, activate the ACK slot (dominant state) regardless if it is interested in the message or not.
The transmitter also monitors the ACK slot, if in dominant state, some other CAN device has heard the message and the transmission is completed.
However, if the ACK slot remains in recessive state, the transmitter assumes that it is disconnected from the bus and repeatedly tries to retransmit the frame.
For any meaningful production testing, an other node is needed, this can be any primitive device (as long as it is not in the Listen Only mode). This test will verify the functioning of the CAN transceiver (and optional optoisolators in the signal paths).
To test jamming, set the external CAN device speed to something different than your actual bus speed. The external device will detect a CRC error and jam the bus.
Yes. The problem is that to properly evaluate adherence to protocol requires a sniffer - much of the interaction is below the level you can observe without one.
A loop test can only prove the single transceiver is alive and that the comparator circuits are functioning - it does not prove that bits are passing through unmangled. But I think I said that previously.
The best you can accomplish with active nodes is to ensure that they are communicating - but they will do that despite some amount of interference and intermittent electrical failures.
To emphasize on Paul's reply: no, you shouldn't. A CAN node alone on the bus will drown in retries and failures as soon as it starts transmitting anything --- it'll move off that zero as far and as fast as it possibly can.
Absolutely. And for really thorough testing, that other node would have to be capable of jumping through quite some hoops as a signal generator, and offer some serious signal processing to ascertain that the device under test is accurate enough to be a good CAN citizen.
I suspect most people instead just rely on CAN's self-testing capabilities, though. I.e. they get a known-good counterpart, have it and the DUT talk to each other for a while, and if there are no error-frames observed, consider the test condition satisfied.
I haven't played with CAN for a while and I am happy to defer to more recent experience, but I can't find support for that in the spec.
There is a note at the end of secti "Start-up / Wake-up: If during start-up only 1 node is online, and if this node transmits some message, it will get no acknowledgment, detect an error and repeat the message. It can become ?error passive? but not ?bus off? due to this reason."
However, in section 6:ERROR HANDLING [2] there is no requirement to retransmit a message that reads back correctly but is unacknowledged - AFAICT that isn't considered a corrupted message. The sending node will detect the NAK error and immediately begin an ERROR frame by transmitting ACTIVE ERROR on the next cycle. The ACTIVE ERROR transmission will cause a further STUFF error on read back, but after transmitting the first ERROR the node goes passive until it reads the 'r' bit [3] that signals the end of the ERROR transmission. At that point it will transmit 7 more 'r' bits and then the error state terminates.
But, AFAICT, that's the end of it - if the transceiver is reading back correctly you get 1 DATA frame and 1 ERROR frame and then the node goes idle. At that point, the transmission error count will be 16 (1 NAK and 1 STUFF) according to the counter handling in section 6.
Retransmission of a valid, unacknowledged DATA frame might be required by a higher level protocol running over CAN, but I can't see anywhere that CAN itself requires it. If you have a reference, I would greatly appreciate it.
George
[1] CAN-1. For CAN-2 see section 8:FAULT CONFINEMENT. [2] CAN-1. For CAN-2 see section 7:ERROR HANDLING. [3] CAN uses NRZ 5:1 signaling and refers to the 2 states as 'd'ominant (hi) and 'r'ecessive (lo).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.