cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong message ID sent on FDCAN

MZadn.1
Associate II

I am using the FDCAN module on STM32H753 to send messages. The message ID is always the same: 0x7DF. So I create a static Tx header:

 

 

static FDCAN_TxHeaderTypeDef txHeader = {
.Identifier = 0x07DF,
.IdType = FDCAN_STANDARD_ID,
.TxFrameType = FDCAN_DATA_FRAME,
.DataLength = 8,
.ErrorStateIndicator = FDCAN_ESI_ACTIVE,
.BitRateSwitch = FDCAN_BRS_OFF,
.FDFormat = FDCAN_CLASSIC_CAN,
.TxEventFifoControl = FDCAN_NO_TX_EVENTS,
.MessageMarker = 0
};

 

 

 and send the message with

 

 

HAL_FDCAN_AddMessageToTxFifoQ(&hfdcan1, &txHeader, txData);

 

 

Next message is sent from HAL_FDCAN_RxFifo0Callback ISR after processing the response to the previous message.

This works fine for some time (~1h), then suddenly, the MCU starts sending messages with ID=0x7FF instead of 0x7DF. I see this on a scope and on the reception side, while the debug log shows that the Identifier field in txHeader is still equal to 0x7DF. Once this occurs, it stays like that for an hour or so, then returns back to 0x7DF and so on.

Any idea?

1 ACCEPTED SOLUTION

Accepted Solutions

I came back to this problem after a month of work on another project, to find out that it was just a *** pointer arithmetic error I made, nothing to do with FDCAN in particular. Sorry for polluting the forum.

View solution in original post

5 REPLIES 5
Karl Yamashita
Lead II

Upload your IOC file so we can see your clock and baud rate settings.

SofLit
ST Employee

Hello,

 

If you are for example using RTOS, change it to bare metal and remove all other stuff not related to the CAN communication and test again and share it so we can have a look.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
MZadn.1
Associate II

IOC file attached, i.e. the one where the problem occurs.

I removed all the code not related to CAN and could not reproduce the problem. Then I went back to the original project and set a watchpoint on writes to txHeader.Identifier. Of course, for this to work, I had to build & run in debug mode (I was running the release mode before). Again the problem didn't appear (not 100% I waited long enough).

Need to investigate further in the next few days, will update as soon as I get some results.

 

It's recommended to use HSE instead of HSI for the clock.

 

Try these recommended settings for the CAN baud rate. 

KarlYamashita_0-1715808827047.png

 

I came back to this problem after a month of work on another project, to find out that it was just a *** pointer arithmetic error I made, nothing to do with FDCAN in particular. Sorry for polluting the forum.