Is STM32L4Cube v1.16.0 RCC_HSICALIBRATION_DEFAULT set up properly for STM32L432KC?

[szabolcs.vereb]

On STM32L4Cube v1.16.0 the RCC_HSICALIBRATION_DEFAULT is set to 0x40, but was 0x10 with v1.15.1 HAL versions. My UART module is using the HSI, hence I need quite precise frequency and it was alright with v1.15.1 (around 0.1% accurate), but after I have updated to v1.16.0, I have around 5% error in the baud rate. I have tracked down the issue and what I see is that RCC_ICSCR register HSITRIM value is set to 0x40 instead of 0x10.

What is more interesting that the datasheet says that the HSITRIM bits shall be set to 64 (0x40), however I read out 0x10 from the MCU after reset.

I am totally confused now. Is the datasheet correct? Is the RCC_HSICALIBRATION_DEFAULT is correct?

As we have around 20 devices which were working properly with the previous Cube version and I read out 0x10 for that register value, I think the datasheet and maybe therefore the Cube implementation is bad.

[Imen.D]

Hello @szabolcs.vereb​ ,

Welcome to the STM32 Community 😊

Thank you for bringing this issue to our attention.

It seems the error is in the latest STM32CubeL4 v1.16.0. I am checking the cube firmware and document and I will come back to you with update about corrective actions we will take.

Imen

[waclawek.jan]

Sounds like a recurring theme...

What if Cube would simply leave the trim alone, leaving it to the user to change when wish to do so arises? I know it's changing the API, but I'd guess the percentage of users actively using that feature is negligible.

JW

[szabolcs.vereb]

@Imen DAHMEN​ Maybe I was not 100% clear in my description. The RCC_HSICALIBRATION_DEFAULT is not directly set in the RCC HAL driver, but the HSITRIM register is eventually will be set through HAL_RCC_OscConfig during initialization. My main issue is that if I generate the source code with CubeIDE, the HAL_RCC_OscConfig will be called in the generated code with RCC_HSICALIBRATION_DEFAULT and I have no tool to prevent the HAL from overwriting HSITRIM reset value. Of course, I can write my own clock config function, but then the purpose of the code generation is kind of broken. Right now I use a macro to redefine RCC_HSICALIBRATION_DEFAULT, but that is quite hacky, and maybe the HSTRIM will change in a future chip revision.

I think a non-API-braking solution could be to have an additional flag in RCC_OscInitTypeDef which can prevent the HAL from overwriting TRIM values.

[Imen.D]

Hi @szabolcs.vereb​ ,

This issue is related to the upgrade from STM32CubeFW version 1.14.0 to the 1.16.0 firmware package, where the default value of the HSI calibration trimming (HSITRIM) on STM32L43xx is updated from 0x10U to 0x40U, and this modification has generated a synchronization problem.

Fix planned in next official STM32CubeFW L4 V1.17.0.

• correction in CMSIS Device files: stm32l431xx.h / stm32l432xx.h / stm32l433xx.h / stm32l442xx.h / stm32l443xx.h

/*!< HSITRIM configuration */
#define RCC_ICSCR_HSITRIM_Pos                (24U)
#define RCC_ICSCR_HSITRIM_Msk                (0x1FUL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x1F000000 */
#define RCC_ICSCR_HSITRIM                    RCC_ICSCR_HSITRIM_Msk             /*!< HSITRIM[4:0] bits */
#define RCC_ICSCR_HSITRIM_0                  (0x01UL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x01000000 */
#define RCC_ICSCR_HSITRIM_1                  (0x02UL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x02000000 */
#define RCC_ICSCR_HSITRIM_2                  (0x04UL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x04000000 */
#define RCC_ICSCR_HSITRIM_3                  (0x08UL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x08000000 */
#define RCC_ICSCR_HSITRIM_4                  (0x10UL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x10000000 */

• correction in HAL RCC file: stm32l4xx_hal_rcc.h

#if defined(RCC_ICSCR_HSITRIM_6)
#define RCC_HSICALIBRATION_DEFAULT     0x40U         /*!< Default HSI calibration trimming value 64 on devices other than STM32L43x/STM32L44x/STM32L47x/STM32L48x */
#else
#define RCC_HSICALIBRATION_DEFAULT     0x10U         /*!< Default HSI calibration trimming value 16 on STM32L43x/STM32L44x/STM32L47x/STM32L48x devices */
#endif /* RCC_ICSCR_HSITRIM_6 */

• stm32l4xx_ll_rcc.h (only comments)

/**
  * @brief  Set HSI Calibration trimming
  * @note user-programmable trimming value that is added to the HSICAL
  * @note Default value is 16 on STM32L43x/STM32L44x/STM32L47x/STM32L48x or 64 on other devices,
  *       which, when added to the HSICAL value, should trim the HSI to 16 MHz +/- 1 %
  * @rmtoll ICSCR        HSITRIM       LL_RCC_HSI_SetCalibTrimming
  * @param  Value Between Min_Data = 0 and Max_Data = 31 on STM32L43x/STM32L44x/STM32L47x/STM32L48x or
  *               between Min_Data = 0 and Max_Data = 127 on other devices
  * @retval None
  */
__STATIC_INLINE void LL_RCC_HSI_SetCalibTrimming(uint32_t Value)
{
  MODIFY_REG(RCC->ICSCR, RCC_ICSCR_HSITRIM, Value << RCC_ICSCR_HSITRIM_Pos);
}
 
/**
  * @brief  Get HSI Calibration trimming
  * @rmtoll ICSCR        HSITRIM       LL_RCC_HSI_GetCalibTrimming
  * @retval Between Min_Data = 0 and Max_Data = 31 on STM32L43x/STM32L44x/STM32L47x/STM32L48x or
  *         between Min_Data = 0 and Max_Data = 127 on other devices
  */
__STATIC_INLINE uint32_t LL_RCC_HSI_GetCalibTrimming(void)
{
  return (uint32_t)(READ_BIT(RCC->ICSCR, RCC_ICSCR_HSITRIM) >> RCC_ICSCR_HSITRIM_Pos);
}

Request is raised internally to correct the RM0394 Rev4 for STM32L43x/STM32L44x devices HSITRIM range

Please mark my answer as best by clicking on the "Select as Best" button if it fully solved your issue. This will help other users find this solution more quickly.

Imen