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?


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.

  • \$\begingroup\$ I have for decades used a variety of approaches for troubleshooting designs; indeed, prior to starting with the ARM earlier this year it had probably been more than a decade since I'd use anything resembling an ICE or ICD. Nonetheless, it didn't take me very long to decide that I like being able to look at program variables without having to add debug code, recompile, reload, and most importantly restart the program under test. It would save a lot of time if I could at minimum have the debugger "rejoin" a running chip. \$\endgroup\$ – supercat Dec 8 '11 at 22:58
  • \$\begingroup\$ @supercat how about a pin-change ISR that kicks it back to normal clocking? \$\endgroup\$ – Chris Stratton Dec 8 '11 at 23:06
  • \$\begingroup\$ The problem is that once the debugger has decided it doesn't like what's going on, there's no way I know of to do anything with it except reset the chip. \$\endgroup\$ – supercat Dec 8 '11 at 23:23
  • \$\begingroup\$ @supercat - I was meaning toggle an I/O to cause a pin change interrupt with an ISR that restores normal clocking, before attempting to utilize the debugger. Another option would be a software debug monitor or stub. \$\endgroup\$ – Chris Stratton Dec 9 '11 at 4:32
  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.

  • \$\begingroup\$ Presently, the board only has the SWD pins connected. It might be possible in future designs to use JTAG if I knew that it would help with the debugging. As for disabling low-power mode during debugging, that sorta works, except when the low-power mode is the thing I actually want to debug (e.g. why in a certain circumstance, the unit will go to sleep, wake up at the right time, but then never go back to sleep). Being able to look at the state of variables at that point would be helpful. \$\endgroup\$ – supercat Feb 7 '12 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.