Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Level 4
Level 4
First like received


I've found a couple watchdog-related issues in the WICED framework:

  1. Debug options are left set in the micro after regular "... download run" make targets are executed.  For example, the DBGMCU_APB1_FZ_DBG_IWDEG_STOP bit in the DBGMCU->APB1FZ register.  Counterintuitively, this means that the debug watchdog will be enabled even though the debugger is not connected, causing a breakpoint instruction to pause the board indefinitely instead of triggering a watchdog reset.  (This may be limited to the STM32F2xx-based platforms, as those are the only ones I've been using.)
  2. When a custom watchdog timeout is specified by the application (APPLICATION_WATCHDOG_TIMEOUT_SECOND=...) the system-monitor period is set to this value minus 100ms, while the debug watchdog timeout is set to 90% of this value.  This means that custom watchdog timeouts other than 1s will not work at all, and timeouts of 1s cause a race that is won by the debug-watchdog timer seemingly at random.

I'm not sure how to address item 1, but I suppose it has something to do with the commands sent to the micro through OpenOCD during programming / reset.  Item 2 was fixed easily enough by making the system-monitor period 80% of the custom watchdog timeout period, though it was very difficult to find given that I had coincidentally set a custom watchdog timeout of 1s, and that it 'goes away' when the MCU's debug register options get cleared (e.g. after a POR reset).


0 Replies