The MCU requires NRST to be toggled after power on

[RobertK]

Hi all, I have a problem with a new version of an existing PCB using the STM32F334C8T6 microcontroller.

Known working code is loaded onto the new PCB, power is applied and the MCU starts up the clock and then seems to sit idle. If the NRST pin is then driven low and released the MCU starts up and begins operating normally. Holding NRST low on power up and then releasing it after a duration does not work, the MCU must attempt to start up and fail first. NRST is connected to a 10kΩ to +3V3 and a 100nF to 0V. BOOT0 is connected to a 10kΩ to 0V.

The signals here (top to bottom) are:
old PCB +3V3
old PCB NRST
new PCB +3V3
new PCB NRST
While both boards were powered at the same time the new board has an additional SMPS stage which adds a small delay to the rise of the +3V3 rail.

The signals here (top to bottom) are:
old PCB NRST
old PCB 8.000MHz crystal
new PCB NRST
new PCB 8.000MHz crystal
I've gone through a couple of stages of being suspicious of the clock as it gets enabled by the code, but then the code seems to stop/stall. However the scope traces don't show any significant problems. I've also compared the clock signal after the reset with the MCU running code and it looks identical to the above scope trace where the MCU is stalled. 

The new PCB does have a different 8.000MHz crystal so I may have got the load capacitors wrong. The new board is using this crystal from JLC with 2x 22pF 0402 C0G load capacitors. Is this correct? Should I be using a different value?

There are other minor differences between the two boards, but nothing that would suggest this issue. e.g. some pins no longer have a 1kΩ resistor linking them even though one pin was never enabled/driven in the code.

I'm running out of hair to tear out so welcome any suggestions of what the issue might be or further debugging steps. Thanks!

[waclawek.jan]

Are all VDD/VSS pins connected, including the analog ones? BOOT0 is connected how?

Try writing a minimal program e.g. a loopdelay-blinky, i.e. no clock setup etc. If it works without the explicit pushbutton reset, then the problem is in your code and you have to debug it in the usual way (maybe hot-connecting the debugger into an already "frozen" system). If it does not work, the problem is likely to be hardware-related.

JW

[RobertK]

All VDD pins go directly to +3V3, VDDA goes to +3V3 via a BLM15AG601SN1D ferrite bead. There are 4x 100nF and 1x 4.7uF capacitors on VDD, 1x 100nF on VDDA. All are ~1.5mm from the pins. All VSS and VSSA pins are directly connected to 0V. BOOT0 is tied to 0V via a 10kΩ resistor.

Once my colleague helps me get an IDE environment generating code I plan to write some simple LED blinky programs with and without the crystal.

[LCE]

While you're waiting for the IDE, maybe change the crystal capacitors to 12 pF.

With IDE, you could try using the HSI to find out if it's the external crystal.

[RobertK]

I'd have to order in 12pF caps, why specifically 12pF?

[TDK]

> The new board is using this crystal from JLC with 2x 22pF 0402 C0G load capacitors. Is this correct?

Not really. Load capacitance of the crystal is 8 pF, so appropriate capacitors would be in the range of 2 * (8pF - 4pF) = 8 pF. Could be the problem, if HSE timeout occurs, but I wouldn't bet on it.

You can attach a debug probe to the chip when it's in the stuck state, without resetting the chip, to find out where the code is at. Probably stuck in clock initialization somewhere.

[LCE]

Okay, 12pF was just a (bad) guess.

I would order a few values between 6p8 and 15p.

[RobertK]

I managed to dig out some 10pF caps. The code still doesn't run and I can't tell any difference in the way the clock starts up

[RobertK]

I now have some code that lights an LED with an 8MHZ signal after the HAL and clocks have been setup, so that works. This pushes the bug to after the clock setup, I guess that while 22pF caps aren't ideal, they're not killing it.

[LCE]

Then good hunting in the software domain!

I would first enable a UART for some printf debugging, then enable the peripherals step by step.
Or taking one after another out from behind... (sounds strange, but I guess you get what I mean)