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]

Correction: they are not exactly the same. I added RCC-related debug prints during startup, and after re-flashing, the issue no longer occurred. Therefore, we concluded that the problem did not reappear after re-flashing, which suggests there is no hardware damage.

Later, I will read the flash contents from another faulty unit to check whether the data inside has changed.

If the flash content has not changed, in your opinion, should I re-flash the original firmware or flash the new version with the added RCC status prints?

[TDK]

> It was found that when the nRST signal had a falling edge, there was no fluctuation on the 3.3V line.

Okay, that's a good check. Hmm.

> should I re-flash the original firmware or flash the new version with the added RCC status prints?

I would leave in the RCC-related debug prints.

It happening intermittently and during water intrusion certainly suggests a hardware fault. My money is still on BOR. Are all solder joints okay? The UFQFPN is harder to solder and inspect than a LQFP. Could be a bad solder joint failing in response to some change in temperature or environment.

Multiple units having the same symptoms also suggests some hardware cause rather than flash corruption (which, again, is absurdly unlikely even as a one-off).

Please post if you figure it out.

[Andrew Neil]

---

@daniaoday wrote:

mounted on poultry

---

So powered by a small battery, then?

I'd think that would support @TDK's brown-out theory ...

---

@daniaoday wrote:

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

---

Does your code write to flash; eg, "EEPROM emulation" ?

[daniaoday]

Yes. A small 50mA battery, a solar panel, a power management module, etc.

We are using two flash sectors as EEPROM. However, I don’t believe the reboot is caused by flash writing, because no flash operations are performed at the time of reboot. That said, it’s possible that during a flash write, a power issue corrupted other memory areas. Tomorrow, I’ll read out the entire flash contents from a failed device and compare it.

Power supply issue:
We reviewed the PCB layout again and noticed that the MCU’s VCC/GND return path is quite long, though we’re not sure if this has an actual impact. If inspection of the RCC_CSR register indicates a power-related reset, then we can confirm this as the root cause.

[MM..1]

Back to images first your VDDA is not connected to 3V3. If realy is then OK , but VDDA without power produce exactly unhandled resets etc.

Nex question si realy required PLL speed in your cade design?  Because switching to create current spikes etc.

Optimal for battery powered is dont use PLL. Last question is how big capacitors is used on power source ?

Showed 4,7uF is very small.

And how is your setup options bytes for BOR level ?

[daniaoday]

Sorry, I uploaded the wrong version— the latest version has already been updated.

VDDA and VDD are now connected together, both at 3.3V, and they won’t power down (unless the battery runs out).

Yes, I need the PLL running at full speed.
Can current spikes be mitigated by increasing capacitance?

Regarding the capacitors:

• At VDDA: 10 nF + 1 µF
• At each of the two VDD pins: 100 nF + 4.7 µF
• At the main power input: 100 nF + 33 pF
• Another IC that also requires 3.3V supply has a 1 µF + 100 nF capacitor placed nearby

The BOR  level is set to the default option byte value—I haven’t modified it in my code.

[MM..1]

50mA batt is how ? Read BOR setup from MCU , is irelevant if your code modify or not...

[Andrew Neil]

---

@daniaoday wrote:

A small 50mA battery, a solar panel...

---

Do you mean 50mAh ?

What technology/chemistry ?

Presumably charged by the solar panel ?

[daniaoday]

The device requires battery power.

This is the system block diagram. The LDO_EN signal can be considered as already enabled.

 An MPPT control IC refers to an integrated circuit similar to the BQ25570RGRR.

I’ll perform unified tests to read the BOR status, RCC_CSR register, and Flash contents tomorrow. Right now, the device is with other colleagues for analysis.

[daniaoday]

Yes, it's a 50 mAh battery that needs to be charged via a solar panel, using a chip similar to the BQ25570RGRR for control. (We didn’t select the actual BQ25570RGRR in the current design due to cost considerations, but we plan to switch to the BQ25570RGRR in the new version.)

We’re also working on optimizing the discharge-related aspects in parallel. However, since charging and discharging details aren’t directly relevant to this issue, I haven’t focused on describing them.

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

In the new reply, I attached a part of the system block diagram.