Debugging STM32LF1xx low-power behavior

Question

Is there any practical way to use a SWD-based debugger such as those made by Segger to debug a program for the STM32LF1xx which uses low-power modes and sets the clock speed very slow? The debugger seems to choke every time the chip is set to an energy-saving mode. It's understandable that debugging won't work while the unit is in low-power mode, but unfortunately once the debugger chokes I can't figure any way to make it work again except to completely reset the CPU. It's possible in some cases to mitigate the problem by using a conditional-compilation flag to disable the code that would put the chip into low-power mode, but this makes it very difficult to troubleshoot the code which puts the unit into and out of low-power modes.

Are there any tricks to allow the debugging tools to work usefully in such situations?

Answer 1

I would be tempted to use alternative debugging techniques such as status LEDs or a serial output displaying progress messages, with both the code concerned and the required peripherals' power enabled by build flags. A lot of work has been done this way on systems where a breakpoint debugger was not available; used creatively it's extremely powerful and with the sub-minute build/flash/test cycles of today, pretty efficient.

Depending on how slow a clock rate you are dropping to, you might still be able to run a serial port at a standard baud rate (300 baud?, 75 baud with short abbreviations). If not, you could do logging via a synchronous protocol like SPI where baud rate can usually be allowed to vary widely, and use another micro-controller as an SPI slave which in turn re-outputs asynchronous data to your PC at a standard baud rate.

It may also be useful to accessorize your SWD debugger with automated control of the reset line; the VL discovery boards do this for the on-board target processor, but it doesn't seem to be part of the SWD connector spec. Also, if you have a firmware that goes into a low power mode quickly after boot, you can usually get the debugger going by holding down reset while commanding single-step mode, thus getting debug access before the mode switch can happen.

Answer 2

1. Try using JTAG mode with Adaptive Clocking.

2. If possible, always prevent code from going into low-power mode during debugging. You might need to have 2 different build configurations to do it, one without low-power modes, one with low-power modes. You could add a special engineering method to disable low-power mode, like read a button or jumper, then the code would change over to a new mode, thus allows you to move back and forth between noormal-power-always or use-sleep-mode.

3. Toggles states on spare pins or LEDs at various points in your code that you are debugging, then hookup logic analyzer to see where your code makes it.