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

[daniaoday]

We re-examined the current issue and found that the power supply problem is indeed more significant. However, the original oscilloscope truly couldn't detect any anomalies. Therefore, we borrowed a higher-end oscilloscope, and the test results were excellent! Although we didn't capture the voltage level during the reset event, we did successfully capture waveform dips at certain moments!

The voltage dropped to around 2.8V. Although it didn’t reach the BOR  threshold, this is very likely the root cause of the issue!

Therefore, we've decided to redesign the power supply and fabricate a new PCB. We hope the next revision will resolve the issue.
P.S.: But why can't we read the flash memory on the failed devices—has it been locked or physically damaged?

[Andrew Neil]

I don't think you've mentioned it but, presumably, your system has some sort of radio link to upload its data?

It is typical of radios to have large current spikes when they transmit - so I guess that's what's happening here?

---

@daniaoday wrote:

the original oscilloscope truly couldn't detect any anomalies.

---

These things can, indeed, be hard to spot - the pulses can be narrow and infrequent.

---

@daniaoday wrote:

The voltage dropped to around 2.8V. Although it didn’t reach the BOR  threshold

---

Well, the one you captured didn't.

You need to check what happens in a worst-case scenario - probably when the battery is low, and the solar cell isn't charging.

Again, does your system log the battery state-of-charge?

BTW: Please use your scope's screen capture facility - it will be much better that photos of the screen!

[daniaoday]

I don't think you've mentioned it but, presumably, your system has some sort of radio link to upload its data? 

--->  Yes, there is a 4G module.

It is typical of radios to have large current spikes when they transmit - so I guess that's what's happening here?

---> Yes 

Again, does your system log the battery state-of-charge?

---> Yes, but at that time the battery voltage was still quite high. 4.0~4.2V . 

These are the monitoring logs from several devices on the platform.

[Andrew Neil]

4G on a 50mAh battery ?!

Seems a bit excessive for this type of application ?

[daniaoday]

Yes, the 4G module manufacturer specifies a peak current requirement of 1 A. Our battery is capable of up to 20C discharge (1000 mA), but the LDO can only supply 200 mA, and the output capacitance is also very small...

[TDK]

Do you write to flash on the devices? This has a large current requirement so the drop could be happening there. 37ms is a long time though. Should be able to capture that on any scope.

If FLASH gets corrupted it may refuse to read out correctly because of the ECC bits. I would imagine doing a full erase can recover the chip. STM32CubeProgrammer may not be set up to handle this correctly.

[Andrew Neil]

---

@TDK wrote:

Do you write to flash on the devices?

---

Yes, they do:

https://community.st.com/t5/stm32-mcus-products/stm32l4-stop2-system-abnormal-restart/m-p/874956/highlight/true#M291899

[daniaoday]

https://community.st.com/t5/stm32-mcus-products/stm32l4-stop2-system-abnormal-restart/m-p/874823/highlight/true#M291868 

It is now confirmed that there is a power supply issue, which under certain conditions can cause the device to reboot. Moreover, it is highly likely that such a reboot occurs concurrently with a Flash write operation.

Summary of the observed behavior:

A device may suddenly start rebooting sporadically (low-probability reboots), confirmed to be caused by the power supply issue.

There was a device that initially rebooted infrequently (low-probability reboots), but at a certain point, its reboot frequency suddenly increased significantly (high-probability reboots). It was also confirmed that reading the Flash memory of this device using STM32CubeProgrammer resulted in errors.

Another device exhibiting high-frequency reboots stopped rebooting after its Flash was fully erased and the firmware was re-flashed (it may still experience low-probability reboots, but this has not been reproduced yet).

[Andrew Neil]

---

@daniaoday wrote:

It is now confirmed that there is a power supply issue

---

Is that the "dip" you showed earlier ?

Do you know what causes that "dip" ?

[TDK]

It still doesn't all add up though. Erasing/programming takes 2.5 mA max which isn't an issue for the battery or LDO. Something else is happening. The drop on the 3.3V line also doesn't look like it's caused by a flash operation. I suspect something else. Bad PCB manufacturing/assembly, or shorting due to water intrusion or something like that. I'm also not sure what to trust and what not to trust out of the info given. Seems like some things have been walked back.