CAN functional test
in [Embedded]
|
Prev: PHY Problems
Next: Start Frame Delimiter
From: Hans-Bernhard Bröker on 29 Jul 2010 16:16 On 29.07.2010 17:57, wrote George Neuner: > 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. 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. > 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. 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.
From: George Neuner on 30 Jul 2010 01:46 On Thu, 29 Jul 2010 22:16:54 +0200, Hans-Bernhard Bröker <HBBroeker(a)t-online.de> wrote: >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. 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 section 7:FAULT CONFINEMENT [1] which says: "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).
From: Hans-Bernhard Bröker on 31 Jul 2010 06:50 On 30.07.2010 07:46, wrote George Neuner: > On Thu, 29 Jul 2010 22:16:54 +0200, Hans-Bernhard Bröker > <HBBroeker(a)t-online.de> wrote: > However, in section 6:ERROR HANDLING [2] there is no requirement to > retransmit a message that reads back correctly but is unacknowledged That's because this requirement is in section 4 or 5 respectively: MESSAGE VALIDATION. > AFAICT that isn't considered a corrupted message. It is. Corrupt equals "any node detecting an error. Sending an error frame somewhat obviously does constitute an error.
From: George Neuner on 1 Aug 2010 00:05
On Sat, 31 Jul 2010 12:50:03 +0200, Hans-Bernhard Br�ker <HBBroeker(a)t-online.de> wrote: >On 30.07.2010 07:46, wrote George Neuner: >> On Thu, 29 Jul 2010 22:16:54 +0200, Hans-Bernhard Br�ker >> <HBBroeker(a)t-online.de> wrote: > >> However, in section 6:ERROR HANDLING [2] there is no requirement to >> retransmit a message that reads back correctly but is unacknowledged > >That's because this requirement is in section 4 or 5 respectively: >MESSAGE VALIDATION. Ah. Somehow I overlooked that. >> AFAICT that isn't considered a corrupted message. > >It is. Corrupt equals "any node detecting an error. Sending an error >frame somewhat obviously does constitute an error. OK. Thanks for clearing that up. George |