Bug in UART code generation in STM32CubeIDE 1.4.2 ?

[DVeda.1]

I upgraded from STM32CubeIDE 1.3.1 to 1.4.2, and got issues with UART speed. To eliminate error sources, I just made a minimum project with UART transmit. At 115200bps, the bit-time should be 8.68us (and it is with IDE1.3.1), but it comes out as 7.82us with IDE 1.4.2, which just gives garble.

The clock config was done with the GUI. This is with HSI clock source. It does not matter if the HSI is used directly or with PLL, still wrong bit-timing. It will give correct timing if the MSI (4MHz) clock is used. I could not see immediately from the code generation what was wrong.

Could you please confirm issue, or is there a work-around, or something I am missing? In the mean-time I need to get back to IDE1.3.

FYI: Chip: STM32L431VC - same issue on both UART1 and UART2.

[TDK]

Check that the value of RCC_ICSCR_HSITRIM is correct. The RM says it should be 0x40, but I would see what it is after reset and use that.

[DVeda.1]

Thank you for the suggesition.

The RCC_ICSCR_HSITRIM is 0x40 after reset, so this is where it should be. The bit-timing error is 10%, so I find it hard to believe that this has anything to do with trimming. Besides the MSI should most likely be worse than the HSI. And works perfectly with IDE1.3.1 (and previous versions). The way I figure, there must be a bug in code generation from the clock config - but it does not seem to be in the upper level (main.c) of the code.

[DVeda.1]

BTW: Figure I will use MSI for now (since that works, also when going through the PLL section in the clock config GUI). So I am good for now, but would still like to see the HSI clock source working, and get to know what the issue is.

[TDK]

If HSITRIM and USART_BRR are the same in both versions, the clock should be the same. Did you check both or just the updated one?

[DVeda.1]

OK - will check tomorrow.

But since the uart is working fine if I use MSI as clock source, would you not think that the USART_BRR would also be good? If the USART_BRR was wrong, then the uart should not work flawlessy with MSI source.

My feeling is more towards that something is wrong with the code generation for setup of HSI source clock. This has been working in previous versions of STM32CubeIDE (1.02, 1.1.0, 1.3.1), but when I now upgraded to 1.4.2, then the uart bit speed is 10.0% too fast. If HSI is routed through PLL or not does not matter, same issue. But if I use MSI directly, or through PLL, then bit-timing is spot-on.

[TDK]

Code generation may be different, but what actually matters is what's in the registers, so that's where I would check first to narrow things down.

[DVeda.1]

Test with MSI 16MHz clock and PLL'ed to 64, UART set to 115200: BRR reads 12 (0x0C). Same test with HSI and PLL'ed to 64: BRR reg reads 12.

(BRR_reg = READ_BIT(USART1->BRR, USART_BRR_DIV_FRACTION) >> USART_BRR_DIV_FRACTION_Pos;)

MSI clock works great, HSI not - 10% too fast bit timing. Both ****** with minimal program, only using UART1, STM32CubeIDE 1.4.2, STM32L431VC.

I have not hand-calculated what the BRR should be, but at least it reads same value for both. So I suspect this has to do with bug in code generation from GUI clock config.

[DVeda.1]

Just an update for reference: I now tested the UART speed with STM32CubeIDE v. 1.5.1, and the issue is still the same. All versions up to 1.3.1 works perfectly, but from version 1.4 this is a problem. Still works fine when MSI clock source is selected, so that is what I am using to get correct UART speed instead of the HSI clock.

[DVeda.1]

New follow-up: I have now tested with STM32CubeIDE v. 1.6 and the same issue persists. This time I also tested generating the RCC code with LL driver selected instead of HAL driver (in Project Manager->Advanced Settings). When doing so, the UART speed is as it should be, also when selecting the HSI as the clock source. As far as I can tell, this must be a bug in the RCC HAL code generation that was introduced around version 1.4 for STM32CubeIDE.

I am not a regular ST community writer, so how do one get ST attention on this issue? (I am fine for now with workarounds, but I think this should be addressed).