STM32L4 STOP2 System abnormal restart

[daniaoday]

Environment: STM32L4 + 32.768K LSE
Function: Wake up and work once every hour, then enter stop2 mode. During the one-hour sleep, wake up every ten minutes to feed the external watchdog.
Problem: The device resets directly when waking up every ten minutes.
Current known information: The device was tested in the company for over twenty days without any issues (including restarts, freezes, etc.). After the prototypes were given to customers, problems started to occur in about 10 to 20 days. Currently, there are two failed devices. After power cycling, the devices did not return to normal. External reset also did not restore them to normal. Re-flashing the devices allows them to operate normally, and they are currently under continuous pressure testing to see if the issue will recur.
Current debugging progress: When the device restarts, the nRST pin has a low-level time of less than 1ms. The 3.3V power supply pin of the MCU is stable as observed by the oscilloscope. The TP5010_DONE_Pin has a 40ms high-level time during each ten-minute wake-up period (HAL_Delay(1) --> SystemCoreClock configured at 80M, after low-power wake-up, it switches to the default 4M of MSI, reducing by 20 times, plus the HAL_GPIO_WritePin time, which is exactly 40ms), but during the first low-power entry, it has a high-level time of over 20ms (caused by unstable PLL switching to MSI?).

------------------------------------------------------------------------------------

2026/02/03 23:18 UPDATE：

Environment:
50 mAh battery + STM32L4 MCU + 32.768 kHz LSE crystal + 4G module + GPS module + solar charging panel

Functionality:

• The device wakes up once per hour to collect sensor data.
• Every 8 hours, it uploads the accumulated data to a server via the 4G module.
• Immediately after completing its tasks, the MCU enters STOP2 low-power mode.
• Data collection and logging are stored in the internal Flash memory.
• During the long sleep period, the MCU wakes up every 10 minutes solely to feed an external watchdog timer.

Problem:
The device occasionally resets during these 10-minute wake-up intervals.

Known Information:

• Our LDO can only supply a peak current of 300 mA.
• There is approximately 10 µF of capacitance on the 3.3V power rail.
• The 4G module’s datasheet specifies a peak current requirement of 1 A. During RF transmission, significant voltage droop occurs—oscilloscope measurements show the 3.3V rail dropping as low as 2.4V.
• The GPS module draws about 100 mA during operation, causing ~100 mV voltage pulses visible on the oscilloscope.
• The Brown-Out Reset (BOR) threshold is configured at 1.7V.

Current Observations & Issues:

• Around twenty devices failed within a few days after deployment, exhibiting frequent reboots followed by permanent disconnection.
• Two faulty units were recovered:
  • One resumed normal operation after reflashing the firmware.
  • The other was not reflashed; attempting to read its Flash memory using STM32CubeProgrammer resulted in errors (see: https://community.st.com/t5/stm32-mcus-products/stm32l4-stop2-system-abnormal-restart/m-p/875450/highlight/true#M291981).
• Logs captured just before reboot are shown here: https://community.st.com/t5/stm32-mcus-products/stm32l4-stop2-system-abnormal-restart/m-p/875962/highlight/true#M292077 (voltage, timestamps, and reboot status are annotated; the column marked "#####" indicates 4G signal strength, which varies without clear pattern).

Current Analysis:

1. Power supply IC limitation: Although we haven’t captured the exact 3.3V waveform at the moment of reset, we have observed dips down to 2.4V. It’s reasonable to assume that under real-world outdoor conditions—especially with poor cellular signal requiring higher 4G transmit power—the voltage could drop even further. (See image showing a 2.8V dip: https://community.st.com/t5/stm32-mcus-products/stm32l4-stop2-system-abnormal-restart/m-p/875903/highlight/true#M292050.)
2. Power cable issue: The current wiring uses approximately AWG16 gauge, which may be too thin, contributing to additional voltage drop.
3. Flash corruption during write operations: Data logging, Flash writes, and 4G transmission occur simultaneously. Therefore, it’s highly likely that a voltage droop-induced reset happens during a Flash write, potentially corrupting the memory contents.

Current Questions:

1. Regarding point #3 above: If a reset caused by voltage droop occurs during Flash read/write, will it permanently damage the Flash memory or only partially corrupt its contents?

Next Steps:

1. Redesign the power circuit: Replace the current LDO with one capable of handling higher peak currents, then conduct further testing.
2. Use thicker power cables (lower gauge) to reduce resistive losses.
3. Investigate and resolve the STM32CubeProgrammer read failure—either recover the root cause or implement mitigation strategies (e.g., robust Flash write protocols, power monitoring before writes).

[TDK]

> A low level on the NRST pin (external reset) → No external reset signal was captured by the oscilloscope.

> However, actual measurements show that the low-level duration on the nRST pin is less than 1 ms.

I'm having trouble reconciling these two statements. You measured the NRST pin was low less than 1 ms (and presumably more than 0s?) but "no external reset signal" was captured? Isn't that the same thing?

If you have a scope capture of NRST when the reset happens:

Create a new project where IWDG is enabled and let it cause a chip reset. That will trigger the same internal pulse generator on NRST. Capture NRST during this event and compare the two. If they're the same, likely it was an internal reset, not external.

[daniaoday]

A low level on the NRST pin (external reset) → No external reset signal was captured by the oscilloscope.
—> This specifically refers to the absence of the TPL5010’s 320 ms wide reset pulse.

I didn’t test using the IWDG; instead, I directly called HAL_NVIC_SystemReset(), and the observed behavior was identical.

The ～1 ms pulse width might be due to the RC time constant: τ = R × C = 10 kΩ × 100 nF (marked as "104") → τ ≈ 1 ms?

[TDK]

Ahh, okay, so likely an internal reset then.

Floating SWD pins will not cause a reset, nor will they affect system stability.

I'm afraid all the potential reset causes are what you listed above. Given your scenario, I think BOR reset is the most likely, though of course this will not happen if power is sufficient.

[daniaoday]

Yes, but the oscilloscope monitoring the 3.3V power rail showed no voltage fluctuations.

[Andrew Neil]

---

@daniaoday wrote:

we confirmed that ... the power supply ... functioning correctly

---

How did you confirm that?

You said the problems only arose when out with customers - so have you looked into the environment where they were deployed?

See this war story - in this recent thread: Best Practices for Debugging Intermittent MCU Freezes on STM32 

[MM..1]

Visual control is not quick. BOR level is set in options bytes and scope require trigger on it... BOR is very sensitive quick detector without spike filter , then nano seconds can reset...

Plus your schematics show VDDA connected, but where ? 

[daniaoday]

I used an oscilloscope to measure a 3.3V signal, and it showed no fluctuations. (Due to the bandwidth limitation of the oscilloscope, nanosecond-level fluctuations might not be captured.) Additionally, I've placed a 100nF capacitor on each power pin—could this issue still occur?

[daniaoday]

The oscilloscope confirmed the 3.3V signal.

The devices are used outdoors, mounted on poultry. Therefore, we conducted EMI-related tests—including electrostatic discharge (ESD) immunity, RF electromagnetic field immunity, and power frequency magnetic field immunity—and all tests passed. As for waterproofing, we once submerged the devices in water for several days and observed no leakage.

Moreover, if we consider hardware damage, why does simply re-flashing the firmware restore normal operation? Could it be flash memory corruption?

Currently, I have two devices —one of them resumed normal operation immediately after re-flashing the firmware.

Additionally, during our attempts to reproduce the issue, we conducted a water-spray test on a pre-shipment unit without its enclosure and observed a similar symptom—this might be a promising lead？

[TDK]

> I used an oscilloscope to measure a 3.3V signal, and it showed no fluctuations.

Unless you were monitoring 3.3V at the time the reset on NRST happened, it means very little. The 4.7 uF bulk caps will ensure power doesn't drop too quickly to see (barring a short). 

> mounted on poultry

haha. Was not expecting that.

> why does simply re-flashing the firmware restore normal operation?

Were the contents changed? Would be useful to check before erasing what was on there.

The flash has error correction. Exceedingly unlikely anything happened there. ECC will cause a hard fault or other non-recoverable error, not an internal reset.

> we conducted a water-spray test on a pre-shipment unit without its enclosure and observed a similar symptom—this might be a promising lead？

Sure is. See if you can read out RCC_CSR on there when it happens.

[daniaoday]

The newly programmed firmware is the same as the original.

The oscilloscope captured 3.3V on one channel and nRST on the other, with the nRST channel set to trigger mode. It was found that when the nRST signal had a falling edge, there was no fluctuation on the 3.3V line.