CAN functional test

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.

I'm using a Freescale 56F8037 as MCU.

Thanks Bye Jack

On Jul 29, 1:13=A0pm, Jack <jack4...@gmail.com> wrote:
> 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 =A0I 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.
>
> I'm using a Freescale 56F8037 as MCU.
>
> Thanks Bye Jack

Test 2 boards at a time

On Thu, 29 Jul 2010 05:13:13 -0700 (PDT), Jack <jack4747@gmail.com>
wrote:

>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.
>
>I'm using a Freescale 56F8037 as MCU.

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.

George

On Thu, 29 Jul 2010 11:57:08 -0400, George Neuner
<gneuner2@comcast.net> wrote:

>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.

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.

On Thu, 29 Jul 2010 19:57:27 +0300, Paul Keinanen <keinanen@sci.fi>
wrote:

>On Thu, 29 Jul 2010 11:57:08 -0400, George Neuner
><gneuner2@comcast.net> wrote:
>
>>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.
>
>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.

George

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.

On Thu, 29 Jul 2010 22:16:54 +0200, Hans-Bernhard Bröker
<HBBroeker@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 &rsquo;error passive&rsquo;
   but not &rsquo;bus off&rsquo; 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).

On 30.07.2010 07:46, wrote George Neuner:
> On Thu, 29 Jul 2010 22:16:54 +0200, Hans-Bernhard Bröker
> <HBBroeker@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.

On Sat, 31 Jul 2010 12:50:03 +0200, Hans-Bernhard Br�ker
<HBBroeker@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&#4294967295;ker
>> <HBBroeker@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