Skip to main content
eng23
eng23
Senior
August 16, 2017
Question

STM32F0 CAN Stops communication

Posted on August 16, 2017 at 21:39

Hello,

I'm working with STM32F0 and CAN communication, sometimes the CAN peripheral stops, doesn't send or receive messages.

In the past I asked the same issue and the answer was that it could be the HAL_LOCK funtion and it will be fix in the next revision. My version of stm32f0xx_hal_can.c is * @version V1.4.0, and now I've updated to V1.8, but the problem still happens.

Has anyone experienced this problem? How  can I fix it?

Thanks.

#can #busy #stm32
This topic has been closed for replies.

12 replies

Tesla DeLorean
Tesla DeLorean
Guru
August 16, 2017
Posted on August 16, 2017 at 22:00

So is it due to the software lock/mutex? or not?

Do the CAN peripheral registers look normal, or are they flagging errors, or stuffed FIFOs?

>>How can I fix it?

The entire library is provided in source form, dig into it a little, if it is a lock issue, check that you and the library properly bracket the usages, and there are no return paths that fail to release it.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
eng23
eng23Author
Senior
August 16, 2017
Posted on August 16, 2017 at 22:15

Thanks for reply Clive,

So is it due to the software lock/mutex? or not?

No, is in normal operation.

Do the CAN peripheral registers look normal, or are they flagging errors, or stuffed FIFOs?

I have a CAN analyser and osciloscope plugged in and doesn't show any error. How can I check if the FIFOs are stuffed?

Debbuging the mcu, the error returned in the function HAL_CAN_Receive_IT is HAL_CAN_STATE_BUSY_RX0, and stay there forever...

Tesla DeLorean
Tesla DeLorean
Guru
August 16, 2017
Posted on August 16, 2017 at 22:23

>>I have a CAN analyser and osciloscope plugged in and doesn't show any error.

Ok, but that's a bit external facing, the software is likely reflecting an internal state, and you'll need to look within the part rather than without.

>>How can I check if the FIFOs are stuffed?

You would need to inspect the internal CAN peripheral registers more directly, the Reference Manual describes the bulk of these, but is a bit opaque due to ST using third-party IP for the bxCAN implementation.

I'd probably use the printf() method to dump internal state, but a peripheral view in the debugger might also provide some insight at the expense of being a bit invasive.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
eng23
eng23Author
Senior
August 17, 2017
Posted on August 17, 2017 at 21:41

Any other idea? Thanks

Tesla DeLorean
Tesla DeLorean
Guru
August 17, 2017
Posted on August 17, 2017 at 22:29

Dig into why it gets stuck in HAL_CAN_STATE_BUSY_RX0 and HAL_CAN_Receive_IT() errors (presumably HAL_BUSY).

How would it normally transition in/out of HAL_CAN_STATE_BUSY_RX0? Why is the RX interrupt not enabled? See where/why that gets turned off but remains in the busy state. Strikes me like there is an exit path that's not covered correctly.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
valentin
valentin
Associate III
August 17, 2017
Posted on August 17, 2017 at 22:23

Ah, yes I have!

The FMPIE registers control whether an interrupt is created on received messages. So you basically want FMPIE0 and FMPIE1 to be enabled all the time.

Unfortunately, ST recently changed the behaviour of their HAL. The CAN error ISR now disables FMPIE completely and you have to restart it manually, which is a pain and caused me to stay with the older HAL firmware (F2 v1.4.0).

Have a look inside the ErrorInterrupt handler. In there, at the very bottom you'll see it disabling the FMPIE.

Solution: You can either hack the HAL and take those lines out or find a way to reliably re-enable FMPIE under all circumstances.

I couldn't be bothered so haven't really got a working solution at hand. But if you find one, I'd be interested!

Btw, once you have that sorted, you should still have a look at the electrical side of things on your bus. You either have termination issues or faulty nodes. Someone is causing the transmit/receive errors.

eng23
eng23Author
Senior
August 24, 2017
Posted on August 24, 2017 at 14:03

 ,

 ,

Hey all,

Well I've got a solution that fix the problem, here we have:

I've commented all the functions calling HAL_LOCK and HAL_UNLOCK in .c file and in the header 'stm32f0xx_hal_can.h' comment the flag CAN_TSR_TXOKx in the macro

__HAL_CAN_TRANSMIT_STATUS

:

♯ define __HAL_CAN_TRANSMIT_STATUS(__HANDLE__, __TRANSMITMAILBOX__)\

(((__TRANSMITMAILBOX__) == CAN_TXMAILBOX_0)? ((((__HANDLE__)->,Instance-

>,TSR) &, (CAN_TSR_RQCP0

/*| CAN_TSR_TXOK0*/

| CAN_TSR_TME0)) ==

(CAN_TSR_RQCP0

/*| CAN_TSR_TXOK0*/

| CAN_TSR_TME0)) :\

((__TRANSMITMAILBOX__) == CAN_TXMAILBOX_1)? ((((__HANDLE__)->,Instance-

>,TSR) &, (CAN_TSR_RQCP1

/*| CAN_TSR_TXOK1*/

| CAN_TSR_TME1)) ==

(CAN_TSR_RQCP1

/*| CAN_TSR_TXOK1*/

| CAN_TSR_TME1)) :\

((((__HANDLE__)->,Instance->,TSR) &, (CAN_TSR_RQCP2

/*| CAN_TSR_TXOK2*/

| CAN_TSR_TME2)) == (CAN_TSR_RQCP2

/*| CAN_TSR_TXOK2*/

|

CAN_TSR_TME2)))

Remember that it is for V1.4.

Thanks for the support!

Terms & ConditionsAccessibility statement