Re: [Openocd-development] STM32 core debug reset problem

[Spencer O. <sp...@sp...>]

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...@ma...>  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