Unreliable can wth STM32F0 and HAL, perfectly reliable with mbed

[Jopj]

I'm having trouble reliably sending CAN messages using the HAL functions (STM32CubeIde) in the way I found in some examples. In those, a message is sent by calling HAL_CAN_AddTxMessage(), but for me that causes nothing to be sent unless I manually clear the INRQ bit with

CLEAR_BIT(hcan.Instance->MCR, CAN_MCR_INRQ);

This way the message gets sent, but soon enough I start getting transmission errors in all mailboxes (TERR bits in CAN_TSR) and message sending stops. It'll occasionally recover with ABOM but still, I must be missing something as this can't be the right way to do it.

My hardware consists of a nucleo-f042k6 connected to a MCP2562 tranciever which is talking to a USB-CAN adapter that is not in silent mode. The bus is terminated correctly, and with code generated using the mbed online IDE CAN is completely solid.

Can configuration (MCR + BTR) is the same for both the STM32Cube generated initialization and what I read from the registers when running the working mbed code. More info in the attached code.

Thanks for any hints to what I'm missing here. Do I need to manually twiddle some bits which the mbed code does automatically?

[mrrosen]

While I cant say for sure if this is your problem, I had a similar problem on a custom board using an STM32F04 and a custom CAN driver. When driving the CAN bus at high speed (in our case it was 1Mbps), the internal HSI48 oscillator seems to have too much variability which lead to eventual CAN Tx errors (specifically in our case, TERR was set as in your case and LEC was Bit recessive error); I notice in your sample code that you too are using that same oscillator for the system clock. By switching to either the external oscillator (should be 24MHz on your board) or the PLL driven by the external oscillator (which is what I ended up doing to get the system clock back to 48 MHz) as the system clock, the CAN bus stabilized and we no longer saw the errors.

I think mbed might be doing this be default though I dont know exactly what youre code looks like for that case. But this post did help me solve my problem and I hope it can help (a year later).

[Jopj]

Good that it was of help!

I never found out exactly what was the issue, but this could be a good lead! I dropped investigating that after I tried out my code outside the nucleo, on the BMS board I was making. There it worked perfectly, and in one case has been running continuously for nearly a year without so much as a single error. That board uses the same uC the nucleo has but in a different package, and the same transceiver. Maybe the one in my nucleo was just unlucky with the variance of its oscillator, although as far as I know it should be enough for can.

[mrrosen]

Probably, as other developers and setups using the our board worked fine (though they too had occasional, strange issues that might be the result of this), it was just my board that seem particularly bad; failing consistently after 2-6 packets (and we werent using ABOM so the failure was "permanent" until reboot).

Just hoping this helps the next person who finds this question :)