Hi everyone,
I am facing an issue with an STM32U5 regarding the entry into STOP3 mode after a production programming cycle using the STM32CubeProgrammer CLI.
I use a .cmd script to flash the device. In the script, I use the -c port=swd dLPM mode=UR flags to ensure the first connection during the multi-step programming of several binaries. At the end of the script, I perform a software reset via -c port=swd dLPM -rst.
After the script finishes and I unplug the ST-Link, the microcontroller fails to enter STOP3 mode (current consumption remains high, in the mA range).
I noticed that if I manually connect with the STM32CubeProgrammer GUI without the "Debug in Low Power Mode" (dLPM) option enabled, perform a software reset, and then disconnect the JTAG/SWD, the device enters STOP3 correctly.
It seems that the dLPM flag used during the CLI session is "sticky": it sets the DBG_STOP and DBG_STANDBY bits in the DBGMCU_CR register, and these bits persist even after the programmer is physically disconnected, preventing the internal regulators from switching to low-power mode.
Is there a specific CLI command to "cleanup" the DBGMCU registers before the final reset to ensure the device is in a production-ready state without debug bits active?
Why does the dLPM -rst not clear the DBGMCU_CR register when the debugger is no longer driving the line?
Is it standard practice to explicitly call HAL_DBGMCU_DisableDBGStopMode() at the beginning of the application code to override settings applied by the programmer?
Any insights on how to properly "detach" the debugger via script to allow immediate low-power entry would be greatly appreciated.
Environment:
- MCU: STM32U5 series
- Tool: STM32CubeProgrammer CLI (v2.21.0)
- Connection: SWD
