Corrupted FDCAN identifiers, 20th bit always set to 1

[nicgreenway]

Hi All

I'm having a problem with FDCAN transmissions and would appreciate any insights.  I have a pair of H563ZI Nucleo boards, and am transmitting FDCAN messages, but the 20th of the 29 bits in the FDCAN extended identifier is always received as 1, regardless of whether it is 1 or 0 when it is sent.

The identifier is set correctly into the Tx FIFO RAM in the HAL layer, but is corrupted in the Rx FIFO RAM when it is received.

There are no reported error states.

This happens not just between the two boards, but also within one board with internal loopback enabled.

Attaching a CAN bus analyser, I can see the corruped identifier on the CAN bus.  So the problem is with the transmit/Tx side, not the receive side.

I've attached the ioc file, but the full source project is under development and wouldn't be very easy to follow; I will try and isolate the problem into a simpler test program, but in the meantime if anyone has seen similar problems any input would be helpful!

Thanks

Nic

[nicgreenway · Accepted solution]

Found it: I was accidentallly using an invalid frame type:

TxHeader.TxFrameType = FDCAN_FRAME_FD_NO_BRS;

FDCAN_FRAME_FD_NO_BRS isn't a frame type, it's a frame format!  Everything generally still worked OK, except for the corruption of the message identifier.

The moral of the story is probably to enable USE_FULL_ASSERT when developing and testing!  The assert_param in the HAL layer would then have caught this.