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
