STM32H750 rev V. SystemClock_Config using LL driver

[JPoha.1]

Hello,

I have met an issue regarding STM32H750 revision change. Originally we used old MCU package v1.5.0 which is not compatible with revision V. It fills wrong value into RCC_HSICFGR register and HSI runs on wrong frequency then. This was fixed in newer MCU packages using HAL but I have found that there probably still is a bug when using LL driver. In SystemClock_Config() there is a line which does not seem to be correct

LL_RCC_HSI_SetCalibTrimming(32);

I would also ask why MCU packages even set this register when it is on correct value after reset?

best regards

Jan

[TDK]

> This was fixed in newer MCU packages using HAL

You sure? Which ones? It's still there in the H7.

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_rcc.c#L488

Edit: oh they actually did fix it, mostly.

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_rcc.h#L7173

[JPoha.1]

> Edit: oh they actually did fix it, mostly.

yes, it seems that it is somehow fixed in the HAL, but not in LL

Actually I do not understand why they even touch these registers, it will be easier to keep the reset value.

[TDK]

Yep, I completely agree. Since trimming is something that needs to be done on a chip-by-chip basis, if at all, it makes no sense to hard-code a non-default trimming value at the project generation stage. Shrug. The LL libraries and code generation in general seem less tested and of worse quality than HAL.