Oct 16, 2014
07:06 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 16, 2014
07:06 PM
Hello,
I've found a couple watchdog-related issues in the WICED framework:
- 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.)
- 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).
Cheers!
Labels
- Labels:
-
SPI
0 Replies