If the chip is powered on too quickly, the chip remains in the reset state

[fhu.11]

The chip is STM32G491. The NRST pin is suspended. The option byte is default value.

I find my board doesn't work after power up, so I measure the waveform of VDD and NRST as figure 1 below.

Figure 1

The green wave is NRST and the yellow wave is VDD. The peak of NRST is 1.7V which is the POR threshold of BOR circuitry.

BOR circuitry will reset the chip until the VDD voltage is above the POR threshold, and then release reset after tRSTTEMPO.

But the chip still remain reset actually in the waveform. The rise time of VDD is about 500us from 0v to 3.3v.

I change the power supply which have a larger capacitance. So more rise time is needed of VDD. Other experimental conditions are the same and I measure the waveform as below.

Figure 2

It can be seen that the reset is released after about 450us, and the rise time of VDD is over 600us. The chip can work well now.

By constantly changing the power supply and adjusting the voltage rise time, I find that the chip will remain reset if the rise time is less than 600us.

I wonder why do these problems occur?

How does the VDD rise time infulence the power up timing?(Please tell me what is the power up timeing? )

[Tesla DeLorean]

The core can run at relatively low voltages.

Is behaviour more predictable with an external POR chip/circuit with a pull-up on NRST?

BOOT0 pulled low?

[fhu.11]

BOOT0 already pulled low

My project is use NRST-pin as a GPIO so there is no pull-up resistor or pull-down capacitor.

It looks like predictable. VDD rise time below 600us will cause remaining reset and above 600us will work well.

I don't understand how the rise time influence chip reset

[Tesla DeLorean]

>>I don't understand how the rise time influence chip reset

Because code does run and then subsequently fails into HardFault_Handler() or Error_Handler() because something died (FLASH access) or failed to start (Clock, PLL). Perhaps generate some signalling in those subroutines rather than die silently in a while(1) loop.

If you're using NRST as a GPIO are we sure we're looking at processor state?

Suggest you put some very simple assembler code in Reset_Handler to drive some other GPIO so you can see if it got there.

[fhu.11]

I think code doesn't run to Reset_Handler because the reset signal doesn't be released yet.

And I already erase all flash before I do this experiment.

[waclawek.jan]

Measure as directly on mcu pins as possible.

Check that all supply and ground pins (including analog) are properly connected, check for bad solder joints. Try on a "known good" board such as Nucleo.

JW