STM32 F7 HAL CAN bug

[Paolo Chiantore]

Posted on March 21, 2017 at 15:31

We are using HAL CAN drivers for STM32 F7 (stm32f7xx_hal_can.c).

During CAN tx/rx stress tests we experienced an issue resulting in CAN receive hang.

The issue is due to a race condition on hcan->State variable between HAL_CAN_Transmit_IT  and CAN_Receive_IT.

The issue arises in the following conditions:

1. hcan->State  is

   HAL_CAN_STATE_BUSY_RX

2. HAL_CAN_Transmit_IT is called and enters condition 

   if

   (hcan->

   State

   ==

   HAL_CAN_STATE_BUSY_RX

   )

3. right after this, CAN_Transmit_IT is preempeted  by a CAN receive interrupt
4. Within the CAN receive interrupt handler CAN_Receive_IT is called
5. CAN_Receive_IT  sets 

   hcan->

   State

   =

   HAL_CAN_STATE_READY

6. HAL_CAN_Transmit_IT resumes execution after the if at point2 and sets 

   hcan->

   State

   =

   HAL_CAN_STATE_BUSY_TX_RX

The final result is that when exiting HAL_CAN_Transmit_IT hcan->State is

HAL_CAN_STATE_BUSY_TX_RX

while it should have been

HAL_CAN_STATE_BUSY_TX

. From now on every attempt of further receptions with HAL_CAN_Receive_IT will fail.

Has someone experienced this issue before?

Are there avilable solutions to this HAL bug from ST?

[jonathan239955_st]

Posted on March 24, 2017 at 10:18

Also came across what looks to be this problem recently, using the STM32F4 HAL drivers. CAN bus worked okay sending infrequent messages, but as soon as I was transmitting a CAN packet once per millisecond (with occasional extras), the rx interrupt would get disabled, and I'd stop receiving anything.

I didn't drill into it quite as much as Paolo, but it sounds pretty similar.

My solution so far has just been to recall HAL_

CAN_Receive_IT after every HAL_CAN_Transmit

_IT

[indrek]

Posted on May 02, 2017 at 10:37

First encountered this issue in 2014 with both F2 and F4. The exact same symptoms as what Paolo described.

Calling HAL_

CAN_Receive_IT again after every HAL_CAN_Transmit

_IT

wouldn't help against

HAL_CAN_STATE_BUSY_TX_RX

, as HAL_

CAN_Receive_IT

would return without any action.

Edit: Wouldn't correct interrupt priorities (identical preemption and subpriorities for both Rx and Tx) resolve the issue?

Edit: Edit: Nevermind, it wouldn't, because the state is changed from a regular function not an interrupt handler. However, a critical section around HAL_CAN_Transmit

_IT

might help.

[yury]

Posted on May 03, 2017 at 07:47

HAL drivers STM32Cube_FW_F4_V1.16.0 seem to have more inner states in attempt to overcome the issue

You may like looking at them and modifying your current F7 drivers accordingly

[jonathan239955_st]

Posted on May 18, 2017 at 15:36

This just seems to add extra states to distinguish between the two RX FIFOs, I'm not sure it will solve the original problem?

[yury]

Posted on May 18, 2017 at 20:49

They also have more rx-tx states and better handling of them , though to me it still seems like band-aid code, just a bit better one

[Imen.D]

Posted on May 03, 2017 at 11:14

Hello,

Please update your firmware package for STM32F4 anf STM32F7 to use the last version as contains HAL CAN update with fix defects and enhancement.

Thanks

Imen

[jonathan239955_st]

Posted on May 08, 2017 at 14:55

What is the version number of the HAL libraries with this fix? I use the HAL libraries through uvision and there doesn't seem to be an update to the software pack they come in. My current version is 1.6 which seems to be from last year (and I believe the version I had the issue with).

[Imen.D]

Posted on May 08, 2017 at 15:08

Hi

van_Beek.Jonathan

,

The last version is

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

V1.0 forHAL drivers version 1.7.1 / 14-April 2017