[bug report] STM32F1 CAN HAL BUG: State locked in HAL_CAN_STATE_BUSY_TX_RX

[justas23]

Posted on May 02, 2016 at 18:13

Hello,

I found that hcan->State was set to HAL_CAN_STATE_BUSY_TX_RX in HAL_CAN_Transmit_IT() when transmission has started.

But successful transmission was not caught and CAN_Transmit_IT() was not called.

After that hcan->State was not reset to HAL_CAN_STATE_BUSY_RX.

So now HAL_CAN_Transmit_IT() cannot initiate a new transmission as it is marked as busy and in case of that hcan->State won't be reset. CAN driver is halted.

I think ST should take more care with drivers as there are too many bugs what makes these drivers useless.

[justas23]

Posted on May 02, 2016 at 22:33

The macro __HAL_CAN_TRANSMIT_STATUS in HAL_CAN_IRQHandler() checks if

''transmission was successful'' AND ''mailbox is empty'' AND ''request completed''.

In case if one of these bits is FALSE, CAN_Transmit_IT() is not called and hcan->Status is not reset.

[Walid FTITI_O]

Posted on May 03, 2016 at 11:41

Hi riabovas.justas,

''The macro __HAL_CAN_TRANSMIT_STATUS in HAL_CAN_IRQHandler() checks if

''transmission was successful'' AND ''mailbox is empty'' AND ''request completed''.

In case if one of these bits is FALSE, CAN_Transmit_IT() is not called and hcan->Status is not reset.''

> I think the state machine implemented is Ok and CAN_Transmit_IT() clear the flags and change the status to ready when the transmission is complete to initiate to the new one.

Have you get in real the can halted ? If you have not trued yet, I suggest that you test with the Cube example ''Can Networking'' given for example in

http://www2.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef4.html

at this path: STM32Cube_FW_F4_V1.11.0\Projects\STM324xG_EVAL\Examples\CAN\CAN_Networking

-Hannibal-

[Marco1]

Posted on May 03, 2016 at 14:24

I don't know if is this problem, but inside the HAL_CAN_Transmit_IT function you can find one ''if'', without else.... I have already sent this bug to support, but without any results.... 

    if(transmitmailbox != CAN_TXSTATUS_NOMAILBOX)

    {

       .............................

    }

    else // myfix porco dio            // add this part

   {                                               // add this part

__HAL_UNLOCK(hcan);  // add this part

return HAL_BUSY;            // add this part

   }                                              // add this part

[justas23]

Posted on May 03, 2016 at 15:36

Yes, CAN in real was discarding new Tx messages.

It that situation I found that

''transmission was successful''

bit was not set and

''mailbox is empty'' AND ''request completed''

bits were set. I was testing my system in erroneous CAN bus network, but I think driver shouldn't lock itself.

Nevertheless I quite fast wrote my own implementation of CAN IRQ handlers based on HAL drivers. These are designed specifically to required application and are shorter and easier to debug.

In my opinion it would be great feature that there were option in CubeMX to select HAL or user implementation of specific functions when generating code. As I left initialization code generated by CubeMX. Moreover many professional programmers say that it might be impossible and inefficient to write drivers for everyone's need in embedded environment.

[justas23]

Posted on May 03, 2016 at 16:29

This bug is known an already fixed in STM32F4 library

[Walid FTITI_O]

Posted on May 13, 2016 at 19:26

Hi macro,

Yes, I see that it is corrected in STM32F4' CAN drivers but not yet with STM32F1.

I will transmit internally your feedback.

-Hannibal-