Potential bug in STM32H HAL v1.8.0: enabling CANFD transmission request for a given packet may disable TX for previous already queued requests.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-10-02 6:03 AM
The 2 instances where hfdcan->Instance->TXBAR is written in stm32h7xx_hal_fdcan.c (as means of activating a TX reqeust for a given CANFD packet) use a direct value assignment to the register:
hfdcan->Instance->TXBAR = BufferIndex;
hfdcan->Instance->TXBAR = ((uint32_t)1 << PutIndex);
From my current understanding of the Reference manual (RM0433 Rev 7) shouldn't these have been "|=" instead? As it is, they will overwrite to 0 non related bits, thus not preserve the TX request of previously queued and yet not sent packets... Or did I miss something on how TXBAR should work?
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-10-06 9:28 AM
Hello @RMart.0​ ,
After checking the spec, it seems that this is not a bug as you described.
In fact, when we write in the FDCAN_TXBAR and we add a new request, the request will be pending and we can verify this in the FDCAN_TXBRP register.
The request still pending untill transmission has completed or the cancellation of the request in the FDCAN_TXBCR register.
So, even if we write 0 in the correspond position of the request in the FDCAN_TXBAR register, the request still pending and there is no risk to lose it.
For more details, please refer to the STM32H7 reference manual (RM0433), in the section 56.5.38 FDCAN Tx buffer add request register (FDCAN_TXBAR)
Please let me know if this point is clear for you and select the post as a "Best" if it answered your question, so that the thread will be marked as solved.
Imen
Thanks
Imen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-10-02 10:14 AM
Hello @RMart.0​ ,
I raised this internally for check and analysis.
I will come back to you soon with update.
Regards,
Imen
Thanks
Imen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-10-06 9:28 AM
Hello @RMart.0​ ,
After checking the spec, it seems that this is not a bug as you described.
In fact, when we write in the FDCAN_TXBAR and we add a new request, the request will be pending and we can verify this in the FDCAN_TXBRP register.
The request still pending untill transmission has completed or the cancellation of the request in the FDCAN_TXBCR register.
So, even if we write 0 in the correspond position of the request in the FDCAN_TXBAR register, the request still pending and there is no risk to lose it.
For more details, please refer to the STM32H7 reference manual (RM0433), in the section 56.5.38 FDCAN Tx buffer add request register (FDCAN_TXBAR)
Please let me know if this point is clear for you and select the post as a "Best" if it answered your question, so that the thread will be marked as solved.
Imen
Thanks
Imen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-10-07 4:20 AM
Yes, your answer makes sense, just saw now that it states in the register full description: "writing a 0 has no impact". Thanks for the help!
