[OpenOCD-user] Resetting a stopped ARM Cortex-M3 target

[Nicolas S. <nic...@gm...>]

Hello,

I've been working on a design using an STM32L151CC, in an application that
requires low consumption. As such, I have been using various run modes of
the MCU, and so far I haven't found a way to access it again from the JTAG
probe after going into STOP mode.
In this mode, only a handlful of things can wake the MCU up: hardware
reset, a rising edge on one of the wakeup pins, or some event on the RTC
subsystem.
The JTAG clock is stopped in this mode.

Therefor, I have been trying to have the hardware reset line toggle before
issuing other commands (like the ones for programming or for starting to
debug), just to be sure the target is in a state where it's possible to
talk to it.

So far I run into the problem of openocd not accepting the reset command
until init has been executed, and init needing to reset the chip before it
can actually talk to the stopped chip...


I use the default stm32ldiscovery.cfg (even if our board is custom, it's
made to keep things like on the Discovery), and stm32l1.cfg - adjusted for
slightly lower adapter speed (240k and 1800k instead of 300 and 2000)

Below are examples where I just try to reset the board, but the problem is
functionally the same if I try to program the board.
Output if I try to reset a stopped board:

openocd  -f board/stm32ldiscovery.cfg -c "init; reset init; reset run; exit"
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read <http://openocd.org/doc/doxygen/bugs.html>
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.188436
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

Makefile:161: recipe for target 'reset' failed
make: *** [reset] Error 1

The same command with a target that is currenlty running:

openocd  -f board/stm32ldiscovery.cfg -c "init; reset init; reset run; exit"
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read <http://openocd.org/doc/doxygen/bugs.html>
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.188436
Info : stm32l1.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0801bbb0 msp: 0x20008000
STM32L: Enabling HSI
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz


In the second case, I can see with the 'scope that the reset line is
properly pulled down.

Trying to just ommit the init command gives me, regardless of the state of
the target:

openocd  -f board/stm32ldiscovery.cfg -c "reset init; reset run; exit"
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read <http://openocd.org/doc/doxygen/bugs.html>
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
invalid command name "reset"
Makefile:161: recipe for target 'reset' failed
make: *** [reset] Error 1


Any way to get out of this catch 22? I did not find a clear way to force
the probe to just toggle the reset line, regardless of anything else.

Thanks.
Nicolas