![]() |
![]() |
Watchdog driver implementation for WiFi F3 devices.
The Watchdog header file should be included in an application as follows:
Refer to Watchdog.h for a complete description of APIs.
The general Watchdog API should be used in application code, i.e. Watchdog_open() should be used instead of WatchdogWFF3_open(). The board file will define the device specific config, and casting in the general API will ensure that the correct device specific functions are called.
This Watchdog driver implementation is designed to operate on a WFF3 device. Before using the Watchdog on WFF3, the Watchdog driver is initialized by calling Watchdog_init(). The Watchdog HW is configured by calling Watchdog_open(). Once opened, the Watchdog will count up from zero to the reload value specified in WatchdogWFF3_HWAttrs. If it times out, a reset signal will be generated. To prevent a reset, Watchdog_clear() must be called to clear the timer, or Watchdog_close() to stop the Watchdog timer.
The Watchdog counts up at the rate of the device clock LFCLK divided by 2^8, which results in a frequency of 128 Hz. The watchdog driver assumes LFCLK is running at 32768 Hz and will not produce accurate timeouts at other frequencies. LFOSC is an inherently inaccurate clock source and will present variations around the target 32768 Hz frequency. These inaccuracies have to be taken into consideration at the application level.
The reload value which the Watchdog timer counts up to may be changed during runtime using Watchdog_setReload(). This value should be specified in Watchdog threshold ticks and should not exceed "2^23 - 1" or fall below "1". At the rate of 128 Hz, the resolution of each threshold tick is 7.8125 ms. This corresponds to a maximum timeout period of 65535992 ms and a minimum period of 7.8125 ms. Calling Watchdog_setReload() will also reset counter value.
The function Watchdog_convertMsToTicks() can be used to convert from ms to Watchdog threshold ticks. If the converted value exceeds or falls below the allowed range, a zero (0) will be returned to indicate overflow/underflow. The period has a resolution of 7.8125 ms, which imposes limitations on achieving certain exact values. When a requested period cannot be precisely implemented, the system will automatically adjust to the nearest possible value within the resolution. For instance, if a period of 22 ms is specified, the actual implemented period will be 23.4375 ms.
Watchdog_close() can be used to stop the Watchdog timer.
No WFF3 specific command exists. Any call to Watchdog_control() will return Watchdog_STATUS_UNDEFINEDCMD.
The Watchdog module available on WFF3 devices does not support debug stalling. Therefore, the Watchdog_Params.debugStallMode parameter in the Watchdog_Params struct must be Watchdog_DEBUG_STALL_OFF will. Calling Watchdog_open() with the debug stall mode to Watchdog_DEBUG_STALL_ON will fail and return a NULL handle.
The Watchdog driver available for WFF3 only supports reset enabled mode, it cannot be used as a timer interrupt, that is, specifying a callback function is not supported by the driver.
Once started, the Watchdog will keep running in Active, Idle and Standby mode. Note that the Watchdog timer is restarted by the Power driver whenever the device enters Standby. If the device remains in Standby for a duration longer than the Watchdog timeout, the device will reset.
| Generic API Function | API Function | Description |
|---|---|---|
| Watchdog_init() | WatchdogWFF3_init() | Initialize Watchdog driver |
| Watchdog_open() | WatchdogWFF3_open() | Initialize HW and set system dependencies |
| Watchdog_clear() | WatchdogWFF3_clear() | Reload Watchdog counter |
| Watchdog_setReload() | WatchdogWFF3_setReload() | Update timer reload value in clock ticks |
| Watchdog_convertMsToTicks() | WatchdogWFF3_convertMsToTicks() | Converts milliseconds to clock ticks |
| Watchdog_close() | WatchdogWFF3_close() | Stop Watchdog timer |
In this basic watchdog example, the application is expected to start the Watchdog timer by calling Watchdog_open(). If needed, Watchdog_setReload() may be called to change the timeout period. If all monitored tasks are doing alright, Watchdog_clear() should be called regularly to reload the counter so as to restart the timeout period and to avoid the Watchdog resetting the device. If the Watchdog_clear() is missed and the Watchdog timer is allowed to timeout, the device will be reset.
The following code example shows how to correctly initialize the driver's parameters, start the Watchdog timer and modify at runtime the timeout period.

Go to the source code of this file.
Data Structures | |
| struct | WatchdogWFF3_HWAttrs |
| Watchdog hardware attributes for WFF3. More... | |
| struct | WatchdogWFF3_Object |
| Watchdog Object for WFF3. More... | |
Variables | |
| const Watchdog_FxnTable | WatchdogWFF3_fxnTable |
| Watchdog function table for WFF3. More... | |
| const Watchdog_FxnTable WatchdogWFF3_fxnTable |
Watchdog function table for WFF3.