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.

[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

[LCE]

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

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

[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)

[RobertK]

I thought I'd managed to narrow the problem down to these lines of code:

InitPinOut( DRV_SLEEP_N );		
InitPinOut( DRV_RESET );		

//SPI
InitPinOut( DRV_SPI_MOSI );
InitPinIn( DRV_SPI_MISO, GPIO_PULLUP );		//TODO check DRV spec
InitPinOut( DRV_SPI_CS );		
InitPinOut( DRV_SPI_SCK );		
spi.format(16, 0); // 16 bit, mode 0
spi.frequency(100000);

//Inputs
InitPinIn( DRV_FAULT, GPIO_PULLUP);			//TODO pullup needed??
InitPinIn( DRV_STALL_N, GPIO_PULLUP);

However none of these seem likely to cause the issue I'm seeing where the MCU seems to reset and then lock up.
I loaded the original firmware on again just to confirm I'm still seeing the issue and it worked. The MCU booted up from power up, ran the code and operates exactly as it should. I have a second board that also exhibited this issue so now my debugging has moved over to this second board. Having the problem magically fix itself worries me greatly.

[ONadr.1]

I would try to cool or heat the board and see if that affects the occurrence of the problem. I would also measure the current of the power source, if the MCU does not fall into some kind of power saving mode. And maybe it wouldn't be a bad idea to activate WDT before setting MCU clock . Although it does not solve the root of this problem, it could solve bad behavior.

 

[LCE]

> ... Having the problem magically fix itself worries me greatly.

But haven't you played with the crystal and the caps? Or did you put it back into the original state?

Edit: maybe the originally assembled crystal caps were not what they should be?

[RobertK]

Hi LCE and others,

You're right! So far I've changed the crystal caps on 5x boards to 6.8pF, 4x of these boards now start up pretty reliably with the 5th still having the issue. It does still occasionally happen on the 4x 'working' boards. So I guess my next question is, how do I measure 'good' for crystal capacitors?

I've gotten the updated value of 6pF from this formula: C1 = C2 = 2 * (CLoad – Cstray) from here: https://microchip.my.site.com/s/article/Calculating-crystal-load-capacitor. The JLC/LCSC part listing says CLoad = 8pF, the consensus seems to be that Cstray is usually around 5pF so I calculate 6pF, and the closest value is 6.8pF. However this is still giving me spotty start up issues, especially when cold (like ~5°C)

Thanks!

[waclawek.jan]

Show us the relevant portion (i.e. around crystal) of PCB layout.

JW

[RobertK]

Okay, it's a 4 layer, 1.6mm thick FR4 board with 2oz copper per layer PCBA.

Top:

Crystal is a 3225 package, left middle. I tried to route the osc pins as a differential-ish signal. Tried to surround them with GND.

Inner 1:

Pour of GND.

Inner 2:

Pour of +3V3

Bottom:

Mostly a pour of GND with some traces. NRST runs under the crystal, and CONSOLE_TX/CONSOLE_RX/TIMING_PULSE are all unused signals crossing at 90deg under the MCU pins.

I think I've done a pretty good job here and there shouldn't be anything iffy about the layout.

[GLASS]

Avoid probing directly hse quartz.

Try a very simple sw based on hsi and not hse to only toggle a gpio.

Be sure of all powering, try to catch with scope very short undervoltage.

Have a look to nrst pin. Try without any capacitor on this pin.

What about option bytes? Try without BROWNOUT reset.