STM32H743 HSI frequency waaaayyy off

[Thomas L.]

At first, let me say that these are my first steps with the STM32H743 so it's really possible I'm doing something really wrong. I've been having issues with the USART which would show that the PC only receives some characters and others have invalid values. So upon sending Hello World, the PC would receive something along the line ".e...W..l." with the characters in between being "wrong".

I then checked on my scope and came to the conclusion that the USART frequency was off by approx 7%. I traced it back and made the STM32 put out the MCO signal of the HSI RC (64MHz) divided by 8. What I get is a whopping ~7.5MHz which is approx the 7% difference I am seeing.

According to the datasheet, the HSI frequency should be off at maximum by about 0.4% (63.7 - 64.3MHz max).

Why am I seeing those 7.5MHz which I do not expect at all and which are .. frankly .. useless.

[Danish1]

Which revision of stm32h743 do you have?

Looking at the reference manual, I see mention of RCC->ICSCR and RCC->HSICFGR depending whether you are on revision V or Y

What do you put into HSITRIM? If it's not the default 0x20 (Rev Y) or 0x40 (rev V) then HSI will be outside the range.

I don't understand where the data sheet says the HSI user trimming step might be as much as 5.2 %

Might you have overwritten the engineering option byte where ST calibrate the HSI? What does HSICAL read?

Is the frequency constant or might it be varying?

The reason I ask is because I had an stm32l4 board that was being starved of power (I hadn't enabled brown-out protection) and the oscillation frequency would vary. Like your observation, some USART characters would come through correctly but not others. So do monitor the supply rail and ensure it is what you expect, and that the regulator has adequate headroom.

Hope this helps,

Danish

[Thomas L. · Accepted solution]

Hi Danish

I just checked and it's a revision V device (so basically the newest revision). I didn't change any of the values of HSICFG. I checked what the framework does. After reset, the values are:

HSICAL: 0x8ec

HSITRIM: 0x0

CSICAL: 0x0

CSITRIM: 0x10

After a call to SystemClock_Config(); those values change to:

HSICAL: 0x8cc

CSITRIM: 0x8

(CSICAL + HSITRIM remain at 0x0)

Where does it say that I need to put 0x40 into that register? and shouldn't it be already there since the manual describes the default reset value as 0x40?

I took a deeper look into the SystemClock_Config call and discovered the following line:

RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;

Yet, RCC_HSICALIBRATION_DEFAULT is set to 0x20 by default ?!?

I changed the line to:

RCC_OscInitStruct.HSICalibrationValue = 0x40;

and it's not a 7.5MHz signal but a nice 8MHz signal - exactely what I'd expect.

Now I have to say that I'm taken away quite a bit. It seems I am using a wrong version of the stm32cube package - but this is the one I got when I selected my part in the part selection dialog. This seems just so wrong on so many levels. Anyone from ST might want to comment on this?

[Thomas L.]

Am I really the only one using that specific IC? Is there really no one which has seen this behaviour?

[Peaga]

Hi Thomas!

Yes, I can confirm this. I'm working with H743 revision X and after porting my project from HAL 1.3.2 to HAL 1.4.0 the CAN hardware stopped working (HSI is the main clock source). After change .HSICalibrationValue from default 0x20 to 0x40, CAN is working again.

I think ST must remove these calibration setting from the clock struct and add them as individual functions, just like what they did for USART FIFO.

[Thomas L.]

Thank you @Community member​ 

This is my first project with an STM and I thought I was doing something fundamentally wrong because it seems to be quite a change for something as essential as the clock structure. This basically renders all UARTs useless if you're using HSI as source.

[Amel NASRI]

Hello,

Issue is reported internally to be fixed in coming releases of STM32CubeH7 package.

-Amel

[MattLogic]

The same issue occurs for STM32L452 (I'm testing with Nucleo-L452RE which has rev "Y" 0x2001 chip) and STM32CubeIDE v1.1.0. I've selected LL drivers for everything, and the generated init code has:

LL_RCC_HSI_SetCalibTrimming(16);

The default trim parameter should be 64 (0x40) for the L452. The Cube IDE config tool for RCC only allows 0-31 for the calibration, and defaults to 16 which throws the HSI16 way off frequency.

[seren]

Same issue here for STM32L451 (with STM32CubeIDE V1.5.0 and integrated MX):

SystemClock_Config()

calls

LL_RCC_HSI_SetCalibTrimming(16);

while in stm32l4xx_ll_rcc.h documentation for this function says:

Default value is 16 on STM32L47x/STM32L48x or 64 on other devices

Since STM32L451 belongs to "other devices" the value should be 64.

A workaround could be to call LL_RCC_HSI_SetCalibTrimming(64) after SystemClock_Config is called but that does not take care for the PLLs that need to be settled.

Please fix this in the next revision.

[seren]

Could you please check, what your internal issue report lead to? At least with STM32CubeIDE 1.6.0, for STM32L451 (see below) the issue still is present.