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.
One can also ponder why you need debug access to something molded in
plastic... Wouldn't it be better to debug your application on a more
lab-friendly setup?
Good point! This is about firmware upgrades in the field as much as
anything. Ideally I'd have liked to use the serial bootstrap loader for
doing that simply, but we have more than a hundred of these devices with
an error in the hardware which means that the USART connection to the
outside world is broken. No problem, I thought, we'll just use JTAG.
I'd like to work out whether the debug unit really does break, or
whether there's just a misunderstanding about state between it and OpenOCD.
Chris
--
Chris Jones - ch...@martin-jones.com
Martin-Jones Technology Ltd
148 Catharine Street, Cambridge, CB1 3AR, UK
Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
