Skip to main content
R
RMart.0
Visitor II
October 2, 2020
Solved

Potential bug in STM32H HAL v1.8.0: enabling CANFD transmission request for a given packet may disable TX for previous already queued requests.

  • October 2, 2020
  • 3 replies
  • 1220 views

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?

    This topic has been closed for replies.
    Best answer by Imen.D

    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

    3 replies

    I
    Imen.D
    Technical Moderator
    October 2, 2020

    Hello @RMart.0​ ,

    I raised this internally for check and analysis.

    I will come back to you soon with update.

    Regards,

    Imen

    I
    Imen.DAnswer
    Technical Moderator
    October 6, 2020

    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

    R
    RMart.0Author
    Visitor II
    October 7, 2020

    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!

    Terms & ConditionsAccessibility statement