STM32F072 reset (NRST) not being released after short power outage or dip

[jmalton]

Posted on March 03, 2015 at 15:44

Hello

I am using an STM32F072 in a simple application.  I have an open-drain reset supervisor on board monitoring a power rail and a pushbutton, driving the same net as the MCU NRST pin, and with an additional 100k pull-up to VDD.  Following a brownout and VDD recovery to 3.3V (or even a power outage of less than about 20 seconds), the supervisor correctly releases the reset signal, but the MCU holds it active (low).  Sometimes it releases it after a few tens of seconds, but often it never does.  (I know it's the MCU, because the behaviour doesn't change if I take my supervisor off the board.) If I leave the supply off for, say, about a minute or longer, then following re-power up, the MCU does not hold NRST active beyond the external supervisor's timeout period, and the MCU starts up as expected.  There is no JTAG or other emulator attached. I know about the multiple reasons for the MCU to drive the NRST pin, but I don't think any of them applies in this case.  The problem is present on boards with both new (never-programmed) parts, and with parts in which I have disabled the VDDA monitor through the User Byte of the Option Register. I have VDD, VDDIO2, VBAT, and VDDA all tied directly to a well-decoupled power plane, and VSS & VSSA to the corresponding common plane.  There are discrete capacitors near each pin, and the power supply appears clean, sourced by a LM25017 buck regulator. The problem is still present even if I short the power rail to force capacitor discharge while the supply is off, then switch it back on.  The power rail rise appears very clean and monotonic. The BOOT0 pin is connected to VSS (plane) with 10k. The manual says that VDDA should be present before VDD.  The Discovery board, however, provides a ferrite bead and 1u/100n filter on VDDA.  I have simply connected VDDA to VDD, since the Discovery solution is in slight contravention of the user guide. Does someone have any similar experiences or suggestions? Thanks #reset-nrst-vdda

[Tesla DeLorean]

Posted on March 03, 2015 at 16:10

Try a more aggressive pull-up, say 1K

[jmalton]

Posted on March 03, 2015 at 18:01

Thank you for your reply. 

I tried a 1k pullup, but it made no noticeable difference. I have 4.7uF on the output of the power supply, and another pair of 4.7uF and a 1uF near the MCU, along with 100nF and 10nF hf decoupling near the power pins.  I'd have thopught that would be sufficient, especially as the Discovery board has only 1uF followed by a diode for bulk capacitance, plus a few 100nF near the MCU.  Do you know if this MCU is particularly sensitive to whatever switching noise I may be introducing with my LM25017 buck regulator?

[Tesla DeLorean]

Posted on March 03, 2015 at 20:00

I'm not using F0 parts.

Ok, now I'm also pretty sure it's an internal source. The POR is connected to the analogue supply. I guess my next questions/tests would be with an external supply, and with BOOT0 pulled HIGH.

[jmalton]

Posted on March 03, 2015 at 20:50

It seems that, using a bench supply instead of the synchronous buck regulator, the MCU resets, releases reset, and runs as one might expect.  But the rails look about the same on the oscilloscope for both supplies, except, of course, for rise time.  My on-board regulator ramps the VDD rail very linearly and monotonically to about 3.6V in 128uS, then drops to 3.3V in the next 30uS or so, then is apparently very stable.

[jmalton]

Posted on March 04, 2015 at 15:52

My current theory is that, during power up, the POR monitor needs VDD above its threshold for some certain amount of time, but in my case, some switching noise that I can't see on my 'scope is resetting that timer.  When the time is finally satisfied, for reasons I don't know, then NRST is released and monitoring switches to the PDR monitor, which is probably a different circuit that watches VDD and VDDA, and that monitor may have different filter characteristics.

I added 100pF to each VDD pin, and that improved the problem, but didn't eliminate it.  This is in parallel with bulk capacitance between the power planes, plus 100nF at the VDD, VDDA, VBAT, and VDDIO2 pins.  (The 100pF was added because the problem disappears completely when I put my 'scope probe across the board's power planes.  Connecting the 'scope ground lead to the board's common plane alone makes no difference.)

[waclawek.jan]

Posted on March 04, 2015 at 23:23

Isn't there something else on the board which parasitic-powers the mcu through its IO pins while the power supply is off?

JW

[jmalton]

Posted on March 05, 2015 at 00:17

A good suggestion, but no.  That was one of the first things I checked.  When VDD falls, all the pins fall.  Shorting VDD to ensure full discharge of the capacitors still leaves the problem occurring.  I'm trying to slow the ramp-up of VDD/VBAT/VDDA/VDDIO2 now, as it seems OK with a bench supply instead of my synch buck regulator, which ramps VDD from 0 to 3.3V in 128uS.

[carl2399]

Posted on March 05, 2015 at 02:02

Sorry, took me a while to realize I've experienced the same condition on an STM32F2xx processor. I would almost be willing to bet money that the same condition exists on the processor you're using.

The STM32F2xx has a brown out reset detector, which is disabled by default (WTF???). The setting is stored in flash, and can be permanently enabled using something like the following:

// Set brown-out register
if
((FLASH_OB_GetBOR() & 0x0C) != OB_BOR_LEVEL3) 
{
FLASH_OB_Unlock();
FLASH_OB_BORConfig(OB_BOR_LEVEL3); 
FLASH_OB_Launch();
FLASH_OB_Lock();
}

You may need to check the parameters for the threshold voltage at which the detection kicks in. Without this setting, it is possible to hang the STM32F2xx processor in exactly the way you describe - although I'm not sure on which planet a hung processor is a saleable feature. Even enabling the watchdog will not reset the processor. Once the BOR circuit is configured, then I was no longer able to hang the processor. It's unfortunate that my customer discovered this ''feature''. Regards, Carl.

[carl2399]

Posted on March 05, 2015 at 02:09

For the F1xx series of processor I used:

/* Enable PWR and BKP clock */
RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);
/* Configure the PVD Level to 2.9V */
PWR_PVDLevelConfig(PWR_PVDLevel_2V9);
/* Enable the PVD Output */
PWR_PVDCmd(ENABLE);