What are the potential reasons for Hardfault?

[dreamcoder]

I have a custom board with a basic crystal oscillator connected to the High Speed Oscillator pins of my STM32F446RET6. I assembled 2 boards and found out only 1 board works fine but the other does not. I replaced the crystal and the capacitors but I still do not see any waveform from this board. I replaced the STM32 as well but still no luck. The STM32CubeIDE can flash firmware and erase it but when I debug it, it always hardfaults at SystemClock_Config(). The power supply to the board is also at a stable 3.3V. As peripherals, the board has CAN transreceivers and an SD card.

What could be the potential reasons for the failure of this board?

[Tesla DeLorean]

Bad or incorrect VCAP implementation.

Wrong HSE_VALUE or PLL settings.

HSE must be turned on manually, should inspect via PA8 MCO pin configuration. ​

[dreamcoder]

@Community member​ Here is the full schematics. Like I mentioned, there are 2 boards and on one the HSE reads the correct frequency but the other board does not. I do read a 1.1V on the VCAP pin. All the other power supply pins do read the correct 3.3V. What else can I test to isolate the issue?

[Tesla DeLorean]

Are you sure its in the Hard Fault Handler, and not the ErrorHandler() while loop?

The part should run from HSI out of startup, and the PLL can also use that clock.

Establish if the crystal not starting is the cause of the issue.

If the wait / dwell time there is sufficient.

If the load capacitors are too high.

Should inspect via PA8 / MCO pin as attaching probes to the crystal will alter board circuit characteristics significantly.

If the board runs at 16 MHz and 180 MHz via PLL+HSI it rules out a lot of other electrical/functional issues.

Instrument code and use a UART to understand internal state and progress.

[dreamcoder]

@Community member​ It was indeed ErrorHandler(). The PLL+HSI works fine and I can see the 16MHz on the PA8. But for my application, the CAN peripheral does not seem to work with HSI, which is why I have HSE in the first place. The HSE circuit is pretty simple and there seems to be no issues at least from the visual inspection on these pins.

[dreamcoder]

@Tesla DeLorean (Community Member)​ It was indeed ErrorHandler(). The PLL+HSI works fine and I can see the 16MHz on the PA8. But for my application, the CAN peripheral does not seem to work with HSI, which is why I have HSE in the first place. The HSE circuit is pretty simple and there seems to be no issues at least from the visual inspection on these pins.

[S.Ma]

If it is possible to plug a debugger, put a breakpoint on the error handler.

The code will stop there and you can see the call stack "the SW line that kills the code"

Check multiple time if the point in code is the same and is repeatable.

Then depending on the result, narrow the marginalities root-causes.