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

[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 ?