Wrong message ID sent on FDCAN
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-12 3:26 PM - edited ‎2024-05-13 11:35 AM
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?
Solved! Go to Solution.
- Labels:
-
FDCAN
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-14 7:20 AM - edited ‎2024-06-14 7:21 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-14 1:02 PM
Upload your IOC file so we can see your clock and baud rate settings.
TimerCallback tutorial! | UART and DMA Idle tutorial!
If you find my solution useful, please click the Accept as Solution so others see the solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-14 6:43 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-15 2:12 PM - edited ‎2024-05-15 2:13 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-05-15 2:35 PM
It's recommended to use HSE instead of HSI for the clock.
Try these recommended settings for the CAN baud rate.
TimerCallback tutorial! | UART and DMA Idle tutorial!
If you find my solution useful, please click the Accept as Solution so others see the solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-14 7:20 AM - edited ‎2024-06-14 7:21 AM
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.
