On 30/10/2010 09:20, Chris Jones wrote:
On 30/10/2010 00:15, Andreas Fritiofson wrote:
On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones<ch...@martin-jones.com> wrote:
But there's a way of breaking it semi-permanently. The application on the
STM32 is one which spends most of its time with the CPU in Stop mode, waking
up periodically (about every 12ms) via an RTC interrupt to do some
processing. If I attempt to start OpenOCD while the microcontroller is
stopping and running like this, I get messages which say,
Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction
and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG
hardware is clearly working to some extent.
The whole JTAG system appears to be then stuck in this state. Restarting
OpenOCD, doing a hardware system reset on the microcontroller, unplugging
everything including the JTAG dongle and its USB interface, all make no
difference. I've even tried exercising the JTAG port using another
application (XJTAG) though this only does boundary scan testing and doesn't
play with the ARM debug TAP. Though boundary scan works fine.
The only thing which fixes the problem is power-cycling the STM32 chip
itself. I note from its documentation and the ARM Cortex-M3 TRM that some
parts of the core debug unit are only reset at power up, not in response to
a system reset. The device has no TRST pin.
However, this board is going to be permanently moulded into a plastic lump
with a battery, so power cycling it is *not* an option.
Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is
wedged, if that's the case, and tickling it back to life?
The debug unit is clocked by the core clock. So, naturally, when you
stop the core clock you'll lose all debug access. There's nothing
OpenOCD can do about it. As Kyle said, you can flip some bits in
DBGMCU_CR to keep the debug unit clocked even in sleep modes. That
will enable you to debug but of course it will also drain your
battery.
Thanks for the hint about DBGMCU_CR. I didn't know that, and it could
prove useful. However, I don't actually want to debug in stop mode. One
thing I failed to mention is that, after a system reset, the firmware
puts the STM32 in run mode until it's sent a command over USB putting it
into the stop/wake cycle. During this time in run mode, debugging
normally works fine.
The problem is that after even one attempt at debugging during stop
mode, the debug unit appears permanently broken and doesn't work in
*run* mode any more. Only power-cycling the STM32 fixes it. Pulling
BOOT0 high during reset and sending the STM32 into its bootstrap loader
doesn't help either.
stop mode debugging (wfe) works fine for me if i reduce the jtag clock
to something like 1kHz, but try even lower if you still have problems.
Cheers
Spen
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
