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?
Best Answer
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.