CAN-FD Protocol Exception on S32K396 not working

[rtljopl]

We are running a S32K396 FlexCAN module in Legacy RXFIFO mode. The channel does not support the Enhanced RXFIFO (channel 4).

We need this controller to exist on a network where some nodes are going to be sending CAN-FD frames.

We have set the PREXCEN bit in CTRL2 that should trigger the protocol exception logic for non supported bits, however the controller still triggers CAN error frames on the bus when CAN-FD frames are seen.

It seems like the protocol exception logic is not active in this case. The controller CAN support CAN-FD, but not in the legacy fifo mode.

From my understanding the Protocol Exception logic should be activated for the FDF bit in the  CAN frame if the controller does not support it. Which is the case in this configuration.

Is this a known issue?

[Julián_AragónM]

Hi @rtljopl,

I am not aware of any open issue regarding protocol exception. 

Are you able to share which RTD version you are using? Is this EB Tresos, S32DS or another configuration tool? I can ask the internal team for confirmation regarding this issue.

If possible, also please share the FlexCAN module configuration, to test this on my side.

Best regards,
Julián

[rtljopl]

This is a custom driver built for our RTOS (rt-kernel https://rt-labs.com/product/rtos/) used in automotive domain. So it's based around the specifications of FlexCAN instead of your provided MCAL's.

We have two variants. One based around legacy rx fifo and one based on extended rx fifo (for can-fd). But since the 4th can controller on S32K396 does not supported extended fifo, we are using the older driver. 

Given it's using legacy rx fifo, can-fd can not be enabled, but it should still be able to passively/silently participate in can-fd networks based on the protocol exception logic. 

[Julián_AragónM]

Hi @rtljopl,

Actually, looking a bit more into the Protocol Exception definition as per-ISO 11898-1:2015, I do not think this configuration is relevant to your setup. 

According to the international CAN conference (iCC): 

When CAN FD was specified in ISO 11898-1:2015, one bit was reserved for the future expansion of the protocol. This is the reserved bit after the FDF bit, which is expected to be dominant in CAN FD frames. When it is seen recessive, a CAN FD node will detect a protocol exception. Software configuration decides whether the node treats this as a form error or whether it enters the Protocol Exception State, where it will remain until the bus is idle again.

Protocol Exception State (PES) is a mechanism for FD‑capable nodes only. Its purpose is not to prevent Classical CAN nodes from reacting to FD frames, rather so that CAN‑FD nodes do not disturb CAN‑XL frames.

A classic controller receiving an FD frame will trigger an error frame, since the bit sequence on the bus does not make sense to it.

Unless you use gateways for older classic CAN nodes in your bus, Classical nodes will throw errors and go bus‑off.

Best regards,
Julián

[rtljopl]

But is this node really a classical CAN node?

I suppose it could be considered that when CAN-FD feature is disabled, however i also assumed it could be run as a CAN-FD tolerant controller when not wanting to receive the CAN-FD frames.

But okey. This won't be solvable by some hardware feature in our case anyway, so we have to figure out a workaround for CAN4 channel without any fifo support.

Thanks for the investigation.

[Julián_AragónM]

Hi @rtljopl,

I think being a CANFD-tolerant node is more dependent on the PHY. For example, TJA1145 will see CAN FD frames as errors, while TJA1145FD offers CAN FD passive functionality, judging the CAN FD frames as 'valid', regardless of what comes after the FDF bit:

Best regards,
Julián

[rtljopl]

Yes we are using the FD variant of that TRCV.

However, the concept of `tolerate` there only applies to wakeup (we had missed that). So once the ECU/TRCV is up and running. CAN-FD frames are passed through to the controller independent on the TRCV setting. So the controller starts sending error frames even though in theory it's CAN-FD capable (thou disabled).

Only way to handle it is to enable CAN-FD on the controller and in software (or probably hardware filters) filter out the CAN-FD frames. But then we are back to the problem of limited CAN-FD support in the 4th channel requiring rewritten drivers.