Continuous watchdog reset on STM32F7

[Squanchy]

The STM32F767ZI on some of my boards has a strange behavior where is goes into continuous watchdog reset.

- Could it be because of ESD? Or is there a known issue with the silicon?

- What could cause the watchdog trigger?

[Danish1]

What do you mean by "Continuous watchdog reset"?

Does the stm32 come out of reset for sufficient duration that you can identify the reset cause as watchdog?

Does your code use IWDG or WWDG (or both or neither)?

At what stage do you enable the watchdog in your startup code?

If you enable it too early, maybe other startup-related things take longer than you allowed for before you enter your main loop and start servicing the watchdog.

What IDE do you use? It is possible for debuggers to freeze various peripherals while the processor is stopped being debugged (including watchdogs, timers) but I imagine the way to select which peripherals get frozen depends very much on the IDE.

Hope this helps,

Danish

[TDK]

Not many details here. Most likely explanation is not a silicon defect but a software bug.

Check option bytes and ensure watchdog isn't enabled by hardware.

[Tesla DeLorean]

Instrument Error_Handler() and HardFault_Handler() so you have some appreciation if it goes into those to die.

What's not happening that would cause the watchdog to fire?

Problem with interrupts not firing, or firing too often.

Remember that if an interrupt source is not properly cleared the CM7 will tail chain endlessly, and no foreground code execution will occur.

Also watch for latent issue in the code, perhaps you loop on a variable that should be volatile, for example, and subtle timing differences cause that code path to be taken.

Generally instrument flow so you can get some idea of how a system arrived in this state.