MCU internal oscillator is not 16Mhz but 18Mhz on some MCU. Why is that ?

[AStef.2]

Hello,

I found this issue that seems that I still can't find the reason.

I am using a STM32F750N8H6 (7BA3Z 9R 1), BGA package on a custom 6 layer board.

I manufactured 11 boards, and within those 11, 8 of them the HSI seems to be at 18Mhz although the HSI is supposed to be at 16Mhz. 3 of them are at the described 16Mhz +/- usual tolerance.

The support components are the ones recommended in the Hardware Guidelines from ST.

Question :

What external factors can affect the HSI to such high extent and with high consistency. The clock is quite stable and the MCU are all shifted nicely to 18Mhz internal clock.

All the MCUs run fine otherwise, all peripherals, albeit all with wrong clocks, works no problem.

The MCUs have been purchased at Mouser and assembled directly out of the box so no tampering before opening the vacuumed bag/tray.

How I checked :

I've checked several ways, the board having a USART 1 and CAN 1 /2 and several timer routed out, all indicate that the HSI is at 18Mhz ~ and 18.2 Mhz for 2 boards.

The code is written based on 16Mhz and work out of the box for the 3 other identical boards, and gives proper reading on timer/PWM output.

Timer check:

The timer parameters I used where for a 500hz+/- 5 Hz output

which gave me a ARR of 32000 with prescaler of 1.

On the suspected 18Mhz boards:

On the Oscilloscope I obtained between 550 and 560 Hz.

Reverse calculating the clock it gives me a clock of around18Mhz for one board for example.

On the 16Mhz more ore less 495~510 more or less

UART

UART set at 115200 gives about ~133k Baud so if set a lower baud, at around 101052 roughly (empirically calculated) it gives a readable TX Output if the terminal on the PC is set at 115200 Baud.

If anyone has any idea on what could be the reason.

The added 2Mhz are quite constant hence the concern.

Regards

Alessandro

[Uwe Bonnes]

Is perhaps some voltage out of range?

[TDK]

Might be worth looking at and comparing HSICAL/HSITRIM between good and bad boards, although I don't think a 12% swing is possible.

Also the UID includes die position, which can show if the bad boards were from a different lot. Chips on the same wafer have almost the same UID.

[waclawek.jan]

Cube?

For some STM32 Cube had bugs changing HSITRIM/MSITRIM inadequately (and nonsensically too). So, as TDK said, check HSITRIM.

JW

[AStef.2]

Thank you all very much for your replies and time you gave to my issue.🙇

Here are the results of the check you suggested:

Voltage out of range ::

At MCU Pins (more precisely at the pins of the bypass capacitors next to them) is 3.28 to 3.29 V for all Boards.

The bypass capacitors are the back of the PCB just below the uC and its VDD/GND Pair pin/via.

The on board PSU can provide 2 Amps to the board, and current consumption is below 30mA so far (at 12V in)

At boot mode 28.64 for 16Mhz board and 29.02mA for 18Mhz board average

The package IDs :

7BA3Z 9R 1 PHL 7B 104 .

The only thing I can understand is the date which I guess is 2021 and the 4th week.

They are all the same for all the chips regardless of their clocks, so as TDK mentioned, they are probably from the same wafer.

RCC registers :

The binary being the same for all boards, but is it possible to generate such differences with the same code ?

I understand the calibration process but it looks like only within small margins so I did not pay attention to this so far.

The RCC Registers are for the 16Mhz boards:

HSICAL： 0x0000FF00

HSITRIM : 0x000000F8​

and for 18Mhz boards

​HSICAL： 0x0000FF00

HSITRIM : 0x000000F8

The clock configuration is as follows. Used HAL to prevent any mistakes on my own, and to be sure that the behavior replicates on all boards the same and using all defaults.

void SystemClock_Config(void)
{
  __HAL_RCC_PWR_CLK_ENABLE();
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_LSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT ;
  RCC_OscInitStruct.LSIState = RCC_LSI_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
 
  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK)
  {
    Error_Handler();
  }
  PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_RTC|RCC_PERIPHCLK_USART1
                              |RCC_PERIPHCLK_I2C2;
  PeriphClkInitStruct.RTCClockSelection = RCC_RTCCLKSOURCE_LSI;
  PeriphClkInitStruct.Usart1ClockSelection = RCC_USART1CLKSOURCE_PCLK2;
  PeriphClkInitStruct.I2c2ClockSelection = RCC_I2C2CLKSOURCE_PCLK1;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_1);
}

Regards

Alessandro

[TDK]

> The package IDs :

The unique IDs are written on the chip in FLASH, not labeled on the outside of the physical package (although some info will be equivalent).

I would open a support ticket with ST if I were you. Seems like something is off.

[TDK]

> HSICAL： 0x0000FF00

> HSITRIM : 0x000000F8​

Are you sure you're reading those correctly? Your code sets HSITRIM to RCC_HSICALIBRATION_DEFAULT which is 0x10 on your chip.

https://github.com/STMicroelectronics/STM32CubeF7/blob/c7c5ec99c7482ea8bcdbf0a869c930af4547088f/Drivers/STM32F7xx_HAL_Driver/Inc/stm32f7xx_hal_rcc.h#L145

[AStef.2]

Dear TDK

Thank you for your reply.

First thank you for the description. I didn't understand it indeed.

After coding a readout I get for a board:

• UID [0] 003F0043
• UID [1] 5030500A
• UID [2] 20333530

Except for X/Y coordinates that change for every chip, the same values across 16 and 18Mhz boards.

Wafer 48 of LOT P0P35 (hope I converted that correctly)

The coordinates however are quite close to each other as X or Y is sequential in the readings

16Mhz chips is Y 44,

18Mhz chips are Y 40,41,42,43 and so on

For the registers I've read the RCC

RCC_CR_HSICAL and RCC_CR_HSITRIM 😅

Not the RCC->CR my mistake, thank you for pointing it out .

HSITRIM shows the default value as expected

but HSICAL shows values that are consistent across "18Mhz" chips and different than the 16Mhz

Across all "18Mhz" chips I get :

RCC-CR 0x00007B83,

HSITRIM 0x10 default value for all boards.

HSICAL 0x7B (<- ??)

For one 16Mhz chip I get :

(same code, except I changed the baud rate to 115200, otherwise I couldn't read the output but that shouldn't interfere I think)

RCC-CR 0x00004E83,

HSICAL 0x4E(<- ??)

For another 16Mhz chip I get :

RCC-CR 0x00005183,

HSICAL 0x51(<- ??)

The calibration value isn't writable by software so would it means that 0x7B is "clocked" at 18Mhz at factory and values below it are clocked at the proper16Mhz +- the calibration value ?

Also does anyone knows what HSICAL translates to ? If it's a value that can be interpreted I thought I could still use the chips...

In the reference manual it's only written that the calibration value is loaded in that register.

With this information I think I will open a ticket as you suggested.

Have a nice day

Alessandro

[TDK · Accepted solution]

Your correct boards have HSICAL=0x50 (approx).

Your incorrect boards have HSICAL=0x7B, which is +43 from the correct ones.

HSITRIM adjusts in steps of about 0.3% (On F4, I'm assuming the same for F7 since the math works out).

https://www.st.com/resource/en/application_note/dm00425536-how-to-optimize-stm32-mcus-internal-rc-oscillator-accuracy-stmicroelectronics.pdf

An error of +43 pushes the 16 MHz intention almost exactly to 18 MHz. (16 MHz * (1 + 43 * 0.003) = 18.064 MHz)

It sure seems like the calibration was just done incorrectly. Rather embarrassing for ST if that is the case.

Unfortunately, the default HSITRIM value is 0x10, which means you can only adjust it by +/- 16, which isn't enough to cancel out the error in HSICAL.

[AStef.2]

Thank you for your reply.

Now everything is clear....:face_screaming_in_fear:

Thanks again and thanks everybody for the help on this issue.

Have a nice day

Alessandro ​