NXP S32K148 Dropping CAN packets

[partis]

Good afternoon

This is probably going to sound a little vague, as much of the software running on this S32K148 is a 3rd party Autosar stack; and the NXP MCAL for FlexCAN is not used, instead it is driven directly by said stack.

Every so often (less than 0.003% of the time); 500ms of packets to be transmitted are not emitted to the CAN bus. The FlexCAN BusOff and recovery is used (ie on silicon and not software). This packet loss occurs randomly, transiently and without any known external triggers; thus we are unable to reproduce on demand. It can sometimes run for 60hrs+ without problem. We'd expect the BusOff recovery to occur within 3ms (based on 500Kbaud and sizable gaps between other bus traffic).

So, this is a rather 'wide' question; but does anything in the S32K148 FlexCAN silicon cause a stoppage of CAN packet transmissions for 500ms?

Kind regards

Gary Partis

[PetrS · Accepted solution]

Hi,

unfortunately I do not see any HW related root of cause within FlexCAN. If SW is preparing TX MB for transmission and the MB wins internal arbitration a message would be transmitted at the first opportunity window on the bus. A node can lost bus arbitration and leave a bus, but I do not guess that.

A automatic bus off recovery takes about that 3ms, but only in case bus is idle, if not it can be extended. TXERRCNT is cascaded with another internal counter to count the occurrences of 11
consecutive recessive bits on the bus. TXERRCNT is reset to zero. It counts in a manner where the internal counter counts 11 such bits and then wraps around when incrementing the TXERRCNT. When TXERRCNT reaches the value of 128, ESR1[FLTCONF] is updated to Error Active, and both error counters are reset to zero. Upon any instance of a dominant bit following a stream of less than 11 consecutive recessive bits, the internal counter resets itself to zero without affecting the TXERRCNT value.

BR, Petr

[partis]

Hi PetrS

Many thanks; and you pretty much confirmed my suspicions

I have used S32K14x devices on quite a few projects; using NXP supplied, non-Autosar (ie not RTD/MCAL) drivers, without any problems. I am concluding that the problem lies in the Autosar stack; but whether the issue is intentional (ie by design) or otherwise, is still being decided.

Again, many thanks

Kind regards