How to trim the STM32 HSI easily

[po221]

Hello

I'm using a stm32L431 with an STLinkV3

https://www.st.com/en/microcontrollers-microprocessors/stm32l4x1.html#documentation

HSI is enabled at 16MHz for USART2, used to receive a 1200Bd signal.

I receive wrong characters because of the trim.

I understood the principle of trim and its registers, in particular thanks to this doc

dm00425536-how-to-optimize-stm32-mcus-internal-rc-oscillator-accuracy-stmicroelectronics-2.pdf

My question: is there a way to adjust this trim automatically via cubeIDE and stlinkV3?

Maybe another solution less practical but more practical than a manual adjustment?

Thanks in advance

[gbm]

It used to be a well known problem with HAL and it probably still is. The HAL overwrites the calibration values for internal clock sources, actually de-calibrating them. So, either do not use HAL, or add two lines of code to main() function - save the RCC->ICSCR to some variable before the clock config call and put the stored value back to RCC->ICSCR after the call.

[po221]

Hello

Thank you for your reply

Do I understand that without HAL the trim is calibrated by default at the time of programming? (by the STlinkV3??)

For the moment I change the trim value manually via cubeMx, so via the HAL layer precisely

[gbm]

Wrong. The callibration value is written to system ROM once by ST during tests. It's transferred to the trim register during uC bootup, then overwritten by HAL firmware for no reason.

[S.Ma]

Use debug mode, and before running the code, check the hw trim register values. After code runs for few seconds, stop the code and check again. If the values have chemged...

Remember that trim is only a first order tuning. HSI will drift in temperature and maybe voltage. The higher the baudrate the more precise the clock must be.

[gbm]

Wrong again. Clock accuracy should be no worse than 2% regardless of the baud rate. This assumes that the other communicating party also has 2% clock tolerance. Relative error should not exceed 4%.

[Tesla DeLorean]

Isn't it one of these things that's depend on temperature and voltage? If I were designing this I'd have a bunch of coefficients, but alas...

Many of the STM32 have a TIM which can measure HSI vs HSE/PLL, I guess "easy" would be to feed a solid 10 MHz in via HSE_IN, or timestamp a 32-bit TIM vs external 1PPS

[po221]

by "easy" I mean, calibrated automatically by an autocalibration (an other source) or by the stlinkV3 pod.

My previous microcontrollers from another manufacturer were calibrated when downloading a program in the flash, by the pod.

I realize that the accuracy of HSI (at worst +/- 4%) should not give me any worries

I am modifying the trim and I cannot correct my problem... some characters are well received, others are crazy.

[Tesla DeLorean]

Well 1200 baud's certainly not something with ppm/ppb expectations. The STM32 method for dividing down, and granularity of the BRR, tends to work against higher frequencies. For lower frequencies you can also tune via the BRR, in APB clock units.

If you're fixturing during programming, or have something else that's crystal derived, and you can generate for the test, or related to equipment you normally attach too, you could always do some time domain measurements of the serial signal, as a reference.

[S.Ma]

Newer parts have usart with autobaud featurr which is problably used in some bootloaders. An easier solution than trimming.

[po221]

L431 has autobaud rate functionality on USART2 !

I'm not sure I understand ABRMOD and ABREN. Is the correction done automatically permanently by the usart?

Thanks

[po221]

It's definitely not a TRIM problem, I was able to reproduce the problem with a usb converter that knows how to transfer data as well.

I opened another topic: parity problem

https://community.st.com/s/question/0D53W00001ixfc7SAA/usart2-on-stm32l431-does-not-support-parity-with-cubemx

Thank you very much for your help and clarification.