In G4 what is the HSI48 calibration default value ? 32 (HAL) or 64 (LL)

[Nikita91]

HAL driver V1.2.2 / 10-November-2021

In stm32G4xx_hal_crs.h:

#define RCC_CRS_HSI48CALIBRATION_DEFAULT 0x00000020U

In stm32G4xx_ll_crs.h:

#define LL_CRS_HSI48CALIBRATION_DEFAULT  ((uint32_t)0x40U)

Both claim:

The default value corresponds to the middle of the trimming interval.

In G4 the TRIM field of CRS_CR is 7 bits, so I think it's 0x40.

[TDK]

Probably 0x40 which is consistent with the RM.

You should be able to read the value after reset to confirm what is on your specific chip.

[waclawek.jan]

Cube notoriously gets the RC oscillators' calibration values wrong. They may be also different number of bits in various models, but that's no excuse.

The primary information source is always RM (+DS/ES/PM), then the CMSIS-mandated device headers. Cube is always tertiary. This is not to say ST won't make errors in RMs (unfortunately).

JW

[Nikita91]

Yes I agree the RM is consistent with LL, and the value is 0x40.

There is indeed a mismatch between LL and HAL for the same MCU. The value provided by HAL is wrong.

[Piranha]

The right value is the reset value, which is 0x40. And the only thing ST's code needs to do is do not touch those values, but understanding such a simple thing is too much for their "developers"...

[Pavel A.]

Surprise! there is NO stm32G4xx_hal_crs.h in the ST official HAL drivers repo :

https://github.com/STMicroelectronics/stm32g4xx_hal_driver/tree/master/Inc

Only stm32g4xx_ll_crs.h.

[TDK]

But there is a stm32g4xx_hal_rcc_ex.h, which contains the RCC_CRS_HSI48CALIBRATION_DEFAULT define and error.

https://github.com/STMicroelectronics/stm32g4xx_hal_driver/blob/master/Inc/stm32g4xx_hal_rcc_ex.h#L518

/** @defgroup RCCEx_CRS_HSI48CalibrationDefault RCCEx CRS HSI48CalibrationDefault
  * @{
  */
#define RCC_CRS_HSI48CALIBRATION_DEFAULT 0x00000020U             /*!< The default value is 32, which corresponds to the middle of the trimming interval.
                                                                      The trimming step is around 67 kHz between two consecutive TRIM steps. A higher TRIM value
                                                                      corresponds to a higher output frequency */

[Pavel A.]

Well, then anyone would like to open a bug on github?

[Nikita91]

Issue opened on github!