STM32H753 STOP Mode inconsistency.

[KP0]

I am using the STM32H753VI chip, it's on a proprietary PCB but the layout is very similar to the nearest NUCLEO board so I am not ready to consider that the issue.

I am working on a very low power application, using CubeIDE but minimal HAL, preferring bare metal. When I execute __WFI() to put the device to deep-sleep, D1 and D2 enter standby (D2 is always standby, actually), and D3 is supposed to stop and allow LPUART1 and RTC to run in autonomous mode (LSE clock). This works exactly as expected, drawing about 250 uA from my power supply (via LDO). The device is set to wake from deep-sleep on LPUART1 RX event. When it wakes, my program can discriminate between the original Power-on Reset and the Wake from Standby. The PWR_CPUCR register is set to 0x1A3, which corresponds to SBF_D2, SBF_D1, STOPF, PDDS_D2, and PDDS_D1 all set, exactly as anticipated.

The issue occurs the next time __WFI() is called. As best as I can tell the settings have not changed, but D3 does not appear to enter STOP mode on the second WFI or any of the subsequent attempts at deep-sleep. The device functions identically, but draws now draws 600 uA. On wake, the STOPF bit is not set. I have dumped the SFRs before and after and compared them with a Diff but I cannot see anything that would explain the failure for D3 to Stop, which prevents STOPF from being set.

EDIT: Errata was not helpful. Additionally, I set the RUN_D3 bit to simulate D3 being stuck on, and as expected the same (undesirable) current draw appears at all times now. Thus, the problem is definitely D3 Running on subsequent attempts to send the device to deep-sleep, but I cannot deduce why this is.

Can anyone suggest some strategies for fixing this? Obvious, not-so-obvious, "secret sauce", any advice would be appreciated.

Thanks!

[KP0 · Accepted solution]

Errata 2.17.x could be doing it, actually. I thought clearing the flags and disabling it would be enough for STOP mode and hence didn't mention it in my first post, but a full reset of the LPTIM with the RCC is what is called for in 2.17.1. I will test this when I can and report back.

EDIT: Did not work, but will comb through the remainder of the Errata to see if something does.

EDIT2: Found it! Didn't appreciate that D3PMRx registers played double duty, and that clearing the bit explicitly (and then re-setting if desired) was needed to send ensure D3 would truly go back to sleep.