Watchdog not paused when debugging

[avrhack]

As far as I can see both from testing and from looking at the source, the watchdog is not paused when at a breakpoint, so any applications that use watchdogs have to have the source code edited before being debugged.

It's trivial for the bmp to set the two flags for the two watchdogs to pause their counters on break.

Something that's been considered and rejected in the past or something that could be done?

[gsmcmullin]

To which target are you referring? I'd be happy to accept a patch. We've
been using the STM32F4 with the watchdog enabled, and it is paused while
the target is halted.

On Sun, Feb 21, 2016 at 9:21 PM, avrhack notifications@github.com wrote:

As far as I can see both from testing and from looking at the source, the
watchdog is not paused when at a breakpoint, so any applications that use
watchdogs have to have the source code edited before being debugged.

It's trivial for the bmp to set the two flags for the two watchdogs to
pause their counters on break.

Something that's been considered and rejected in the past or something
that could be done?

—
Reply to this email directly or view it on GitHub
#117.

[avrhack]

It was an STM32F303 so surprised it is fine on your STM32F4 as I can't see any code that would halt the WD. You positive the WD is working normally? Also, which WD are you using as one is synchronous and I'm using the other one :)

[UweBonnes]

I also see no code to disable the watchdogs. But disabling Timers and watchdogs during debug is best done in the debugger startup file.

[esden]

Do we have a conclusion on what should be done here? Do we want/need to patch this before the V1.6 release? I think stopping the asynchronous watchdog when halted is probably a good idea. I am just not sure if that can be done in a generic manner or needs to be done per chip family.

[UweBonnes]

>>>> "Piotr" == Piotr Esden-Tempski ***@***.***> writes:

Piotr> Do we have a conclusion on what should be done here? Do we Piotr> want/need to patch this before the V1.6 release? I think stopping Piotr> the asynchronous watchdog when halted is probably a good idea. I Piotr> am just not sure if that can be done in a generic manner or needs Piotr> to be done per chip family. This mmeds to be done in a chip specific way...

…

-- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

[fabalthazar]

Currently, hosted blackmagic does not stop watchdogs so if embedded BMP firmware does not either, one faces difficulties to program Flash or whatever long operation if a watchdog is started by hardware (in option bytes) or if a previous program started it.
Otherwise the Flash has to be erased and/or option bytes changed then power off the chip. This can lead to hassle situations when frequent reflashings.

Is their a situation where it is profitable not to stop watchdogs when halted?

Ideally the hosted BMP would provide an option for this purpose and targets drivers would have a corresponding callback.
We can see other IDEs and utilities proposing such option (at least for STM32 A.F.A.I.K).

[UweBonnes]

Assuming a cooperative program on the target is unprobable. In the device probe function, the status of those stop-inhibit bits should be stored in the target (device-private) structure, the bit set so that no miss-hap happens. On detach, the original bits need to be restored. But this needs to be done on a per-device base. And it needs to be tested on a per-device base, Nobody has all the devices. So patches are welcome!