CAN BUS Stress Test

Luca Giuliodori · ‎2018-03-30

Posted on March 30, 2018 at 14:48

I'm testing one application with 3 differente device that send a message with random command ID and random data on CAN bus every random timeout: two devices with two STM32L433 nucleo and one with STM32F446 nucleo and with TJA1044T NXP transceivers.

I implemented firmware starting with STMCube (rev. 4.0) and added my application code with all corrections that I found in the community.

For first test the command ID random range was between 0 to 50 and the timeout random range was from 10ms to 1s. In this case all work enough fine without errors or packet lost.

In second test I reduced the timeout random range and was between 1ms to 10ms. In this case some errors appear and some packet lost; In particular the most freqeuntly errors was BIT ERROR (BR error).

To stress the application again I reduced the command ID random range to 1 (only command ID 0) and set the timeout to 1ms fixed: every ms all the boards (not sincronized) send the same command ID. In this case the number of errors (BOF, STF, FOR, ACK BR and BD) and lost packets increase a lot.

To evaluate the number of errors and lost packets, I implemented specific counters

that I can read by PC SerialPort when the test is stoped.

The frequency of CAN bus is 1Mbit/s, I calculated the timing by

/external-link.jspa?url=http%3A%2F%2Fwww.bittiming.can-wiki.info%2F

(Tq = 5ns, BS1 = 13, BS2 = 2, SJW = 1) and I used a very short cable (about 30cm).

In alltests the number of sent packet by every board are about 000.

My question is: is normal this behavior? I didn't found materials in intertet about this.

#can #stm32f4 #stm32l4

Note: this post was migrated and contained many threaded conversations, some content may be missing.

T J · ‎2018-03-31

Posted on March 31, 2018 at 23:32

You cannot violate the basic CanBus principle.

Randomly, I think you may stumble across it.

No two devices can transmit the same MsgID at the same time, or you will have bus contention.

Yes, by all means, randomise everything, but dont violate the rule.

The linedriver, The T version is the worst one, at max 1MHz.

if you think you need 1MHz, use the other better parts, that work upto 5MHz.

at 1MHz ? its a very high rate.

30cm is ok, do you have a terminator ?

do you have a scope ?

how did you connect all the grounds together with a thicker wire ?

maybe best to look at the waveform. and make sure you don't violate the rule.

You may need a tighter pull up on the Rxpin like 1K, but with a line driver you shouldn't need it.

Luca Giuliodori · ‎2018-04-03

Posted on April 03, 2018 at 09:47

T J wrote:

You cannot violate the basic CanBus principle.

Randomly, I think you may stumble across it.

No two devices can transmit the same MsgID at the same time, or you will have bus contention.

Yes, by all means, randomise everything, but dont violate the rule.

Ok surely there will be bus contentions but should not be the peripheral to solve the contentions and try to resend (I disabled 'non-automatic retransmission)?!

The linedriver, The T version is the worst one, at max 1MHz.

if you think you need 1MHz, use the other better parts, that work upto 5MHz.

What are the other better parts? Can you seggest me some links or documents about this one?

at 1MHz ? its a very high rate.

30cm is ok, do you have a terminator ?

do you have a scope ?

how did you connect all the grounds together with a thicker wire ?

Yes, I have a terminator resistance at 120 ohm and I connected all the ground with a

thicker

wire, from one device to other one.

maybe best to look at the waveform. and make sure you don't violate the rule.

'violate the rule', w

hat do you mean?

You may need a tighter pull up on the Rxpin like 1K, but with a line driver you shouldn't need it.

Yes I'm using a transceiver and also I think that I shouldn't need a pull-up but I can try.

T J · ‎2018-04-03

Posted on April 03, 2018 at 11:34

the data sheet is suggesting there are different parts within the family:

The TJA1044 implements the CAN physical layer as defined in ISO 11898-2:2016 and

SAE J2284-1 to SAE J2284-5. The TJA1044T is specified for data rates up to 1 Mbit/s.

Additional timing parameters defining loop delay symmetry are specified for the other

variants. This implementation enables reliable communication in the CAN FD fast phase

at data rates up to 5 Mbit/s.,

https://www.digikey.com/products/en?keywords=tja1044

the TJA1044GT is the slow part, the TJA1044T is the fast one.

sorry, no, its not surely,' the peripheral will solve the contentions and try to resend'

if you have two transmitters sending the same msgID at the same time, there will be bus contention outside the range of the CAN specification. where the message owner is identified by the lowest address/message ID.

these two units will pass the address stage thinking they are the valid master of this packet

and if they send opposing data in any form,the CanBus will lock up.

I couldn't resolve the errors without a power down.

otherwise we saw no errors at 250khz.

AvaTar · ‎2018-04-03

Posted on April 03, 2018 at 11:58

if you have two transmitters sending the same msgID at the same time, there will be bus contention outside the range of the CAN specification. where the message owner is identified by the lowest address/message ID.

This is no realistic use case for CAN, which assumes a static bus setup (nodes and messages).

A contention, i.e. identical ID from different nodes, is supposedly a configuration error (designer mistake), and not well handled at runtime.

Luca Giuliodori · ‎2018-04-03

Posted on April 03, 2018 at 14:14

the TJA1044GT is the slow part, the TJA1044T is the fast one.

I verified and I'm using TJA1044T; it should be right. There is an error in the main question (now corrected).

if you have two transmitters sending the same msgID at the same time, there will be bus contention outside the range of the CAN specification. where the message owner is identified by the lowest address/message ID.

these two units will pass the address stage thinking they are the valid master of this packet

and if they send opposing data in any form,the CanBus will lock up.

Ok it's right.

With 'automatic retransmission' the peripheral try to resend the same message until he has sent the message and generate error if arbitration lost, right?

T J · ‎2018-04-03

Posted on April 03, 2018 at 14:18

no, in my experience the locking mechanism only relates to the period where the MsgID is being transmitted.

if two units pass this point with the same MsgID, then the PCB will lock up until you power it down.

Luca Giuliodori · ‎2018-04-03

Posted on April 03, 2018 at 14:24

Ok but consider the following instance: a network with n-devices and on power-on (after sleep or after power-off) every device send its info (with random timeout); in this case all devices send indormation with same msgID and could happen some device send message at the same time.

Luca Giuliodori · ‎2018-04-03

Posted on April 03, 2018 at 14:29

Excuse me but what do you mean by:

locking mechanism
the PCB will lock

AvaTar · ‎2018-04-03

Posted on April 03, 2018 at 14:35

I'm not claiming to be a CAN guru, but again, this is not a CAN use case IMHO.

in this case all devices send indormation with same msgID and could happen some device send message at the same time.

This should not happen, as it is (IMHO) a configuration error.

In our network(s), each node includes his node ID in it's messages, which is unique (like a IP address in TCP/IP networks).

If using CANopen, consider LSS to assign IDs.