STM32L152 resets due to external ESD events

[radar_macgyver]

I have a board with an STM32L152 that occasionally resets itself when an 'external' nearby ESD event occurs - for example when I sit down at my desk and my finger draws a spark to the desk. This only seems to happen when the ST-Link debug cable is attached, I have not yet got it to replicate without the cable.

The RST input on the STM32 is connected to a 4.7k pull-up with a 100pF capacitor to ground. It goes to both the JTAG/SWD cable connector and to a board-mounted manual reset pushbutton switch. The total net length is about 70 mm.

I had tried replacing the capacitor with 100 nF but the internal reset mechanism of the STM32 stopped working properly (ie, calling NVIC_SystemReset() fails to work as expected since the RST pin is internally pulled low by the STM32). The 4.7k pull-up value comes from the STM32 eval board. Various sources online talk about using a larger capacitor value, but these always reference other STM32 series (such as the STM32F4xx or STM32F1xx) which lack the 20 us pulse generator on the reset pin (see attached figure from the reference manual).



Is there some way I can harden my board from spurious resets? So far I've not observed them without the debug cable attached, but that could just be chance.

[AndyC_772]

This sounds like a problem that'll be much more easily answered with a photo of the board and any cables attached to it.

[radar_macgyver]

Fair enough - here's a top view of the board as it's sitting on my bench. All the I/Os have an LC filter (a ferrite and a 100 pF or 1nF capacitor depending on the speed), with the exception of the programming header (it's labeled 'J14 STDC', to the right and bottom of the micro). You can also see the 'RESET' push button switch. In the final application, it will have a shielding cover over most of the board but that's been removed during development.

During development, it's in a relatively benign environment (except for the occasional 'nearby' ESD zap). There aren't any high currents flowing nearby. All of the reset events I've seen so far have always been triggered by ESD in the vicinity (about 1 meter away).

Other things of note:
1. The STM32 gets its clock from an 8 MHz oscillator, not a crystal.
2. STM32 runs on 3.3V from an AZ1117IH-3.3 LDO that converts down from 5V.
3. The 5V comes from an LTC4413 'ideal diode' that ORs power from two independent 5V sources, both of which are active.
4. Same behavior seen on multiple copies of the board, so it's unlikely to be due to a flaky solder joint or other assembly errors.

[thm_w]

I don't think reset function should fail with 100nF, that is shown in the official ST docs: https://www.st.com/resource/en/application_note/an3216-getting-started-with-stm32l1xxx-hardware-development-stmicroelectronics.pdf

100pF seems too low.

You can try getting rid of the pullup though.

[incf]

You may wish to consider 47 or 100 ohm series resistor(s) at the connector. Possibly even higher series values for the reset line.

[radar_macgyver]

How strange - replacing the 100pF with a 100nF and removing the pull-up works now in terms of being able to do a software reset. Previously, when I had a 100nF and 4.7k pull-up, the board would start up just fine, but a software reset would not work. Observing the nRST line with a scope showed the 20 uS pulse applied by the reset circuit but it did not go low enough. I will leave the debugger cable plugged in and see if a spurious reset event occurs again. Maybe the pull-down FET is too wimpy to sink the current from the external pull-up? Thank you @thm_w for the post. I figured reading the RM was good enough, I guess there's even more ST documentation I need to read...

@incf The idea is to form an RC filter with the cap? It would be good but would require a board respin.

Open to any other suggestions on preventing spurious resets.

[incf]

Yes. The resistor drastically limits the amount of EMI coupled onto the reset trace on the PCB. Often, the parasitic capacitance of the traces on the PCB are "sufficient" and little to no external capacitance is required.

[Venturi962]

FYI, the schematic on the Nucleo L152RE page only shows a 100 nF capacitor on the NRST line.  I'm not sure I've seen external pullup in other designs.

[radar_macgyver]

The Discovery board for this chip does have a pull-up, but it's marked as not fitted, I must have missed that.



It still doesn't explain why having a pull-up makes the noise tolerance worse. The internal pull-up value is not specified, but I would guess it's fairly high (20-40k range). Installing a 4.7k pull-up would drive the nRST pin high (inactive) more strongly than the internal pull-up, wouldn't that make it more tolerant of noise pickup?

Also, to @incf's point, the STM32 Discovery board does have 22 ohm resistors in series with all the JTAG/SWD lines. I should have had those on my board, but again, missed it.



For what its worth, the board has run overnight without a reset after replacing the capacitor with a 100nF.

[Venturi962]

Sounds to me that there's a few things working in combination:

- 4.7k pullup is too strong, causing internal reset to break
- 100 pF is too little, ESD pulses may not be suppressed, causing reset

Would be interesting to see what impact the 100k pullup has as indicated on the ST schematic.

[radar_macgyver]

FYI, the schematic on the Nucleo L152RE page only shows a 100 nF capacitor on the NRST line.  I'm not sure I've seen external pullup in other designs.

I just reviewed the Nucleo board schematic for something else and found that it shows a 4.7k pull-up and a 100nF capacitor. Please see the link below: Never mind - I was looking at the wrong pushbutton switch.

https://www.st.com/resource/en/schematic_pack/mb1136-default-c04_schematic.pdf

The Nucleo board has two STM32s, one is for an embedded STLink implemented in an F103, which has a 100k pull-up. The mystery deepens...

From my notes written while developing the firmware for a previous board that used an L152, I had noted that issuing a software reset (with the recommended 4.7k/100nF) causes the micro to hang. The implementation of NVIC_SystemReset() sets the SYSRESETREQ bit, then enters an infinite loop. I'm thinking that on that particular board I may have had a fluke STM32 that wouldn't work with the 100nF cap.

*edit: grammar, and the big goof noted above.

[incf]

I'm inclined to think the pull-up-resistor-strength hypothesis might be a red herring.

That pin is very sensitive to AC/HF/EMI

[radar_macgyver]

It seems that way - the ribbon cable used with the ST-Link is short - only about 300 mm. That's apparently enough of an antenna to pick up noise and reset the CPU.

For future reference, I've attached a table from the STM32L15x data sheet with the nRST pin characteristics. The logic thresholds are different from the regular I/O pins, as is the hysteresis and filtering. I interpret the V_{F(NRST)} and V_{NF(NRST)} parameters as the minimum pulse width that gets filtered out, and the maximum pulse width that won't get filtered out, though I would have named it t_{F(NRST)}.



Thanks all for the inputs on this. I think that using the 100 nF with no pull-up is the way to go, it's recommended by ST and it seems to be working so far ie, no spurious resets seen yet. Normally, I would see several in the course of a day.