cancel
Showing results for 
Search instead for 
Did you mean: 

When configuring an STM32L452RE on the NUCLEO-L452RE, there is a difference in the HSI16 clock speed depending on whether configuration is done by HAL or LL.

JSawa.1
Associate II

Configuring the NUCLEO-L452RE via HAL using nothing but the default values for the board in STM32CUBEIDE and setting PA8 as the master clock output to monitor HSI16, the clock frequency at PA8 is 16MHz. When configuration is done via LL (Project Manager -> Advanced Settings), the clock frequency at PA8 is 14.7MHz. The ICSCR register has these values:

HAL: HSITRIM 0x0

HSICAL 0x9b

LL: HSITRIM 0X10

HSICAL 0X6b

The Reference manual shows that the HSICAL value is read only, so I assume it should be loaded at reset by the hardware, and not under software control. I need to set the HSICAL to the correct value while using LL. How can I do this? Note that by setting the HSITRIM to its maximum value only brings the HSI16 up to 15.4MHz while the HSICAL value is 0x6b.

1 ACCEPTED SOLUTION

Accepted Solutions

> However, I cannot change it to 0x40 because I get a pop up error notice saying that the value is out of range.

That then sounds like bug in the debugger.

Incorrect HSITRIM values in various Cube components have a long history. So perhaps just try avoid them in any way you can. The easiest way is to not use Cube at all.

JW

View solution in original post

5 REPLIES 5

What you read out from RCC_ICSCR.HSICAL is a sum of the the factory-programmed value plus content of RCC_ICSCR.HSITRIM. You can try it in a debugger: write into HSITRIM and after that read out (in some debuggers, "refresh register view") HSICAL - it will change with changing HSITRIM.

> HAL: HSITRIM 0x0

I doubt it. The default value of RCC_ICSCR.HSITRIM, corresponding to nominal 16Mhz, is according to RM0394 rev. 4, page 196, 0x40.

How do you check this? Read out post complete content of RCC_ICSCR.

> LL: HSITRIM 0X10

This is certainly a problem. It should be 0x40 as I've said above.

JW

Thanks for the reply, waclawek.jan

Indeed, the values I wrote are accurate. I am reading them with a debugger. As you say, when I change HSITRIM, HSICAL also changes. However, I cannot change it to 0x40 because I get a pop up error notice saying that the value is out of range. When configuring the HSI Calibration Value in STM32CUBEIDE (LL), the default value was 0x10, so I left it at that.

The function LL_RCC_HSI_SetCalibTrimming is used by the LL SystemClock_Config. That function has this in its comment:

 * @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

Since I am using the STM32L452, I should be able to program 0x40, as you say. When I try to enter that value in HSI Calibration Value in STM32CUBEIDE, it automaticallly changes the value to 0x10. When I change STM32CUBEIDE's auto generated code:

// LL_RCC_HSI_SetCalibTrimming(0x10);

 LL_RCC_HSI_SetCalibTrimming(0x40);

I can measure 15.7MHz at PA8 where I used to measure 14.7MHz. HSITRIM read by the debugger shows 0x0. So, it looks like there is a bug in STM32CUBEIDE.

TDK
Guru

> HAL: HSITRIM 0x0

> HSICAL 0x9b

> LL: HSITRIM 0X10

> HSICAL 0X6b

Sure seems like HAL HSITRIM is 0x40 and you're misreading it. Otherwise the values are not consistent. Otherwise HSICAL would be 0x5B.

You don't say or show how you're reading these values. Perhaps there is an issue in the SVD file.

If you feel a post has answered your question, please click "Accept as Solution".

Yes, I am sure HAL HSITRIM is 0x40; I think what is happening is that the 0x40 is changed to a 0x0 byt the IDE. Only the displayed value is incorrect.

HAL is ignoring the value in HSI Calibration Value; rather, it is programming this in SystemClock_Config():

 RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;

LL on the other hand is using the HSI Calibration Value, which is why it was 0x10 when I didn't change the default value originally provided by STM32CUBEIDE.

> However, I cannot change it to 0x40 because I get a pop up error notice saying that the value is out of range.

That then sounds like bug in the debugger.

Incorrect HSITRIM values in various Cube components have a long history. So perhaps just try avoid them in any way you can. The easiest way is to not use Cube at all.

JW