Incomplete frame trigger the error active event?

[卓儒陈]

We found a problem that when we initialize SBC to change the transceiver mode to active mode, CAN bus is disturbed and error frame on bus may occurs.

First our MCU initialize our CAN controller inside MPC5604, then we initialize CAN transceiver in SBC(UJA1164) to let the transceiver mode change from Offline mode to Actice mode.

One of the difference between Offline mode and Active mode is CAN Line in the transceiver is floating or real connecting to CAN bus.

So, when we change the transceiver mode to Active mode, CAN Line of transceiver connect to the CAN bus and the transceiver is able to receive signal on bus and convert the signal
as CAN_Rx(TTL) to MCU. At this time, MCU may receive an incomplete frame when bus load is high. So this situation trigger Error Active event in MCU, which let MCU send a stuffing
error frame purposely to inform other nodes on bus that there is some mistake on bus.

So, am I right if MCU receive an incomplete frame will trigger the error active event?

Waiting for your reply, thanks so much!

[martin_kovar · Accepted solution]

Hi,

yes you are right. The CAN protocol automatically handles protocol errors in hardware - this is what makes CAN robust. If a CAN node receives a message with an error it can destroy the message and cause the transmitter to resend. The CAN node destroys the message by sending an error frame.

Whether the error flag will be passive or active depends on the node status.

Regards,

Martin

[卓儒陈]

Thank for your support.

I also wonder how to avoid this error frame, because our ECU may start up after other ECUs have already started to send frames on bus. And does this situation cause some risks so that we must avoid it or just it affect nothing we could ignore it?

I suggest to initialize SBC first, then initialize the CAN controller in MCU, but our colleague said that

"the CAN driver initializes the CAN controller and waits until it is initialized.
But the CAN controller cannot be initialized until there is a recessive level on the CAN Rx line. If you have low bus load it might be possible that the time between the messages is enough to initialize the CAN controller. But with high bus load there is not enough (idle) time on the CAN Rx line. This means the CAN
driver waits forever and this will cause a watchdog reset."

But I think recessive level must appear on bus because the stuffing rule.

[martin_kovar]

Hi,

Your suggestion about SBC initialization and CAN controller in MCU initialization is correct. But your colleague has also true. You need at least 11 consecutive recessive bits space. Look for example to the MPC5604B reference manual (rev. 8). On page 464 is written:

Once out of Freeze Mode, FlexCAN tries to resynchronize to the CAN bus by waiting for 11 consecutive

recessive bits.

http://cache.freescale.com/files/32bit/doc/ref_manual/MPC5604BCRM.pdf?fsrch=1&sr=1&pageNum=1

In CAN specification is written that interframe space last for 3 recessive bits, which is the minimal time. It could be longer in some cases (error passive node).

But if you do not have 100% bus load, there should be sufficiently large spaces to connect the node.

Staffing rule is irrelevant in this case.

Regards,

Martin

[卓儒陈]

Also remind that 11 consecutive recessive bits will never appears in data field because of stuffing rules in order to ensure if receive 11 consecutive recessive bits it means bus is idle.

[martin_kovar]

Hi,

we are talking about the same. You are correct that 11 consecutive recessive bits never appears in data field because of stuffing. But I thought that you have to have time of 11 consecutive recessive bits between frames to connect new node.

If you do not have 100% bus load then there are spaces between frames which last long enough.

Regards,

Martin

[卓儒陈]

Hello, I'm afraid that I don't agree "But if you do not have 100% bus load, there should be sufficiently large spaces to connect the node." after I read Bosch CAN standard.

11 consecutive recessive bits (Bus Idle) must appear because ACK Delimiter is 1 recessive bit next to the delimiter is End of frame, it consists with 7 recessive bits, then interframe space last for 3 recessive bits.

I think this is the purpose why MCU synchronizes itself to the data transfer on the CAN bus by waiting for the occurrence of a sequence of 11 consecutive recessive bits(Bus Idle) before it can take part in bus activities and starts the message transfer. After synchronize event, the first frame CAN controller can receive must be a complete one.

So we should initialize transceiver first. But aslo thanks so much for your help!

[卓儒陈]

The information is very helpful to me. Thanks so much for your help.