2022-11-02 07:34 AM
I'm using Nucleo STM32L011K4T6 kit to test different low-power features.
For this, the code is executed in RAM for 10ms (GPI/Os management) then the MCU is put in stop mode with the WFI instruction, to be woken up 90ms later by the RTC (RTC wake up).
This works fine if the Flash memory remains valid, but if I disable the Flash memory (RUN_PD and SLEEP_PD bit of the FLASH_ACR register), the code seems to run only once.
I obviously checked that all the code (main code and code under interrupt) is indeed in RAM, unfortunately when I disable the Flash memory, in debug mode in STM32CubeIDE, I get the error message "Target is not responding, retrying..."
If I put a breakpoint on the WFI instruction and restart the execution of the code with the F8 (resume) function, then the code is executed correctly.
If I run the code with the F5 (Step into) or F6 (Step over) function, then the code runs correctly.
But if I remove the breakpoint and I restart the execution (F8) the error message "Target is not responding, retrying ..." appears 10 times, and the debug mode stops.
Does anyone have an idea about the problem?
2022-11-02 07:42 AM
Did you enable debug in low-power modes at the beginning of main?
DBGMCU registers block has different bits that let you control how (and if) devices becomes debuggable in different ULP modes.
You can then do things like:
SET_BIT(DBGMCU->CR, DBGMCU_CR_DBG_SLEEP);
2022-11-02 08:57 AM
Hi Tilen,
I did that, but it doesn't change anything, always 10 messages "Target is not responding, retrying..." then "Shutting down..." then "Exit".
Laurent.
2022-11-02 09:45 AM
Which tool chain? The ST ones, or Keil, IAR, Segger ones?
Generally it's hard to debug/connect when the power is off on the scan-chains, etc.
Is there a way to do this without the debugger inserting itself into the problem?
Is there a secondary way you can stop/alert the system to your desire to connect externally?
Or for that matter provide telemetry about the issue you're trying to identify/solve?