The issue of clock configuration for STM32F446RCT6

[乒乓]

Why is it that when I set the clock frequency of the STM32 to a high frequency (180 MHz), the code will crash, but when I set it to a low frequency (72 MHz), the code can run normally?

[乒乓]

The external crystal oscillator is indeed 8 MHz.

[mfgkw]

I was not in doubt about the osc value on paper, but its real value.

Anyway, what's the use of resistor R20?

[乒乓]

The external clock is indeed 8 MHz. R20 is NC and no resistor is connected to it. When I tried the clock frequency at 80 MHz, the system would frequently enter the void HardFault Handler (void).

 

[mfgkw]

Ok, then it should be 8 MHz.

Your clock intitialization looks like 100% autogenerated by CubeMX for 180 MHz.

Can you determine, when it runs into the error handler?

[TDK]

R18 should not be there.

Crystal appears to have 20 pF load capacitance so load capacitors should be about 2 * (20 pF - 5 pF) = 30 pF.

Guidelines for oscillator design on STM8AF/AL/S and STM32 MCUs/MPUs - Application note

What does the hard fault analyzer say is the reason for the hard fault?

Likely there is nothing wrong with the clock settings if they were generated by CubeMX. Try these settings on a known good board such as an ST Nucleo if you have one.

[乒乓]

When I was conducting a single-step debugging, I reached the line: if (HAL RCC ClockConfig (&RCC ClkInitStruct, FLASH LATENCY 5)! =HAL OK) At this point, he directly entered the "void HardFault Handler (void)" section.

The clock configurations were all generated by CubeMX. I didn't make any changes and I'm not sure what the reason is.

[乒乓]

As shown in the above figure, this is the clock I configured with CubeMAX. The external clock is 8 MHz and the main frequency is 180 MHz. Then the code generated by CubeMAX is as follows: 

phenomenon：
        The clock is configured correctly and there is no reason for the code to crash in the "HardFault_Handler" function. However, when the configuration is set to a lower frequency, the code can run normally.
 cause：   
       The "bus wait" for Flash read operation is not effective.Although you have set FLASH_LATENCY_5 in your code, there might be the following issues at high frequencies: __HAL_FLASH_SET_LATENCY() is executed too late (for example, after PLL configuration but the Flash has  already been accessed at high frequency);The Flash voltage calibration of the chip has not been completed, resulting in the "actual non-effectiveness" of the 5 wait cycles configuration.
 The solution is as follows：
      Move the Flash wait cycle configuration to be performed before the PLL configuration (modify SystemClock_Config()).

[mƎALLEm]

Hello @乒乓 ,

I have a doubt regarding the measured frequency value with the oscilloscope here. 8.32MHz with a crystal of +/-10PPM!

Your oscillo screanshot:

So Could you please do two tests:

1- Measure the clock on one of the MCO outputs:

Example:

Do you get 8MHz?

2- Run your code with HSI at the same system clock frequency with the same flash latency. Do you get the same issue: getting a hard fault?

[wegi01]

Yes for me this 8.32MHz was immediately suspected. But if it really simply enought use without OC at 168MHz. By the way I did overclock NUCLEOF446 up to 240MHz it was work without any problem.