CAN functional test
in [Embedded]
|
Prev: PHY Problems
Next: Start Frame Delimiter
From: Jack on 29 Jul 2010 08:13 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
From: cbarn24050 on 29 Jul 2010 08:46 On Jul 29, 1:13 pm, Jack <jack4...(a)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. > > Thanks Bye Jack Test 2 boards at a time
From: George Neuner on 29 Jul 2010 11:57 On Thu, 29 Jul 2010 05:13:13 -0700 (PDT), Jack <jack4747(a)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
From: Paul Keinanen on 29 Jul 2010 12:57 On Thu, 29 Jul 2010 11:57:08 -0400, George Neuner <gneuner2(a)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.
From: George Neuner on 29 Jul 2010 14:18
On Thu, 29 Jul 2010 19:57:27 +0300, Paul Keinanen <keinanen(a)sci.fi> wrote: >On Thu, 29 Jul 2010 11:57:08 -0400, George Neuner ><gneuner2(a)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 |