Hi,
On 2010.01.12 05:17, David Brownell wrote: > On Monday 11 January 2010, Michel Catudal wrote: > >> That is correct. As for the watchdog, once you enable it you can no >> longer debug as it keep reseting. >> > Isn't there an STM32-specific register to prevent the watchdog > from counting while the core is in debug halt state? > Yes it is - called DBGMCU_CR, located at 0xE0042004. Few debuggers (particularly not IAR) directly manipulate it, but it is writable from user application. Both IWDG and WWDG watchdogs can be stopped while core is halted with this somewhere in the beginning of init code (i.e. before configuring and enabling *WDG): DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP; Source: §20.15.3 in STM32 Reference Manual UM0306. This register is also writable by debugger when core is held in reset condition, thus it makes sense to set it up in reset-init event handler in Tcl. > That's the solution I'm used to seeing on other cores. And I > thought I saw docs for at least one Cortex-M3 core saying they > had that solution. Maybe it wasn't STM32. > > > >> I will test this on the weekend to see if this is still true. >> Right now for debugging I have conditional that disables the watchdog if I >> want to debug. >> I have the same problem with IAR so that is not an openocd problem. >> > Of course, entirely disabling the watchdog can work too! > Running application under development with IWDG disabled can have disastrous consequences, even having no direct intention to debug-halt core in mission critical code sections. Been there, know that. Later I surrounded those sections with DBGMCU_CR &= ~DBG_IWDG_STOP and DBGMCU_CR |= DBG_IWDG_STOP. > I do that with WFI: if debugging, just busy-wait in the idle task. > Otherwise the clock gating prevents me from talking to the core; > it's idle most of the time, after all! > Same DBGMCU_CR register with DBG_SLEEP and/or DBG_STANDBY bits set might help here - it allows clocking FCLK and HCLK from internal RC osc when core is in SLEEP or STANDBY modes, thus JTAG remains alive and well, just somewhat slower :-) Regards, Audrius Urmanavicius _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
