HSE Crystal Oscillator and FDCAN on STM32C092: message is not being sent

[Neiliow]

ST moderator edited the title to give more visibility on the issue/subject

Hello,

I have a board with an STM32C092KCU6 where the main clock is using the HSI48 internal oscillator but I also have an 8MHz crystal for the HSE oscillator to use for FDCAN for higher precision. When the HSE is clocking just the FDCAN module the CAN does not work.

I can get the CAN to work by using HSI48 as the FDCAN clock source. I can also get the CAN to work if I use HSE as the main clock (but it is too slow) or if I enable the clock output MCO2 with HSE as its source or also if I enable the RTC module and set HSE as its source.

So it seems that the HSE oscillator will only work if it is being used on FDCAN + one other place.

Osc for core	CAN clk	RTC clk	MCO2	CAN working?
HSI48	HSE	-	-	No
HSE	HSE	-	-	Yes
HSI48	INT	-	-	Yes
HSI48	HSE	HSE	-	Yes
HSI48	HSE	-	HSE	Yes
HSI48	HSE	-	HSI48	No

I first thought this was a gain margin or a drive problem but I calculated that Gm is 7.57 for the crystal I have used. Also, my colleague has tried this on a C092 Nucleo board and says he can see the same thing.

Any clues as to what the problem might be would be appreciated.

Many thanks.

[Neiliow]

That is correct.

Also if you enable HSE as the clock source for the RTC it works correctly.

I think I said that right at the start but maybe it wasn't clear.

[mƎALLEm]

Ok thank you for the confirmation. That's strange but I suspect something wrong in the HAL

Before I need to test the behavior from my side next week on a NUCLEO-C092 board.

[mƎALLEm]

Hello,

Looking at your attached project, I see the FDCAN is not set to the Loopback mode but in Normal mode.

So I need a working project in Loopback mode where I can see the transmitted frame on PB1 with MCO2 enabled and no message transmitted when MCO2 is disabled. Please test the project before to attach it.

Thank you for your understanding.

[Neiliow]

OK, attached are 2 projects to run on a C092 Nucleo board which I have verified as showing the problem. The CAN data is present on "cantest_nucleo_HSE_MCO2" but not present on "cantest_nucleo_HSE".

Note it is on PD0 and PD1 on the Nucleo board, not PB0/1 as you said.

Thanks.

[mƎALLEm]

Thank you & well received.

I've reproduced the behavior. Need time to investigate it. I will keep you informed as soon as we find the issue.

[mƎALLEm · Accepted solution]

Hello,

After doing the difference between both code sources, I noticed the following line was different:

Working:

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;

Not working: 

 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;

So it seems like CubeMx does generate the code related to HSE only if we enable something related to HSE example enabling MCO2 to output HSE or setting the system clock to HSE but it doesn't generate the code related to the HSE when only HSE was selected as source clock for the FDCAN.

I'm escalating this behavior to CubeMx team for analysis and for eventual fix. 

So from your side, in RCC configuration, replace:

 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;

by:

  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;

and it will work. For sure you need to replace these lines each time you generate the code.

Internal ticket number for follow-up: 217709 not accessible by the ST community members.

This post will be moved to CubeMx forum board as it seems to be a CubeMx issue.

[Neiliow]

Excellent detective work! Thanks for that. I'll do what you suggested until there is a fix in place.

Thanks again.