On 2010.01.13 00:06, David Brownell wrote:
> On Tuesday 12 January 2010, Audrius Urmanavicius wrote:
>
>> 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.
>>
> Odd; I'd have expected that it's the debuggers which would set that!
> Do you know why they don't?
>
>
I have no reasonable idea to support this. I can only speculate that it
is either chip-dependent issue and there's no general approach, or IAR
stays on safe side and disallows WDT stopping by default (as I mentioned
previously, behavior can be overridden in user code).
>> 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.
>>
> Yeah -- if you're going to use a watchdog, it's safest not to turn it off.
> When you're using halt-mode debug it's sort of unavoidable though...
>
> Thing is, a watchdog is a global constraint device, so I don't see how
> guarding it like that only for critical sections would help.
>
>
("mission critical section" of algorithm should not be confused here
with "code critical section", e.g. surrounded by resource locking
primitives).
The project contained a software PID controller, and I halted core in a
state when PID's output was quickly ramping up - PWM output had duty
cycle close to 100%. As I manually debug-halted core, PWM was still
running, this time uncontrolled with same high duty cycle. That blew up
quite expensive mechanical equipment, it took few days to repair it.
Right after that I added if()'s in code that turns off DBG_IWDG_STOP bit
when PID is away from set point by some value, preventing halting core
without immediate WDG reset. Manipulation of this bit at run-time has no
consequences for normal flow of operation nor WDG, except when halting.
If someone happens to halt core again in critical part - MCU would just
merely reboot and switch off its outputs.
Regards,
Audrius Urmanavicius
>>> 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 :-)
>>
> I don't actually use STM32, but I did seem to recall noticing that it it
> provided a relatively complete set of controls to make on-chip debug be
> less painful than on some other chips. :)
>
> - Dave
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
