The ESX when powered up starts the internal watchdog counter. However, the WD is not armed until the first time its state is toggled. The function wd_triggern() normally does that unless a WDminTime > 0 is defined and wd_triggern() is called BEFORE the WDminTimer has expired. In that case, the WD does not get armed! A subsequent endless loop will NOT cause the controller to reset!
//---------------------------------------------------------
Example Application:
-> application initializes watchdog in the beginning and calls wd_triggern()
-> application then goes into a 5 sec. loop, trying to force the WD to reset the ECU
Example #1:
Given:
-> bWDminTime = 137 (= 70ms)
-> wd_triggern() is called aprox. 22ms after system power up.
-> application then enters a 5 sec. loop without any further wd_triggern() call.
Result:
Because wd_triggern() is called BEFORE the mintime of 70ms is expired, the watchdog remains disarmed and the controller will not reset.
//---------------------------------------------------------
Example #2:
Given:
-> bWDminTime = 41 (= 21ms)
-> wd_triggern() is called aprox. 22ms after system power up.
-> application then enters a 5 sec. loop without any further wd_triggern() call.
Result:
Now wd_triggern() is called AFTER the WDminTime is expired and thus within the valid time-window, which in turn arms the watchdog and subsequently causes the watchdog to reset the controller due to the 5 sec. while(true) loop.
FAZIT:
When using a "window-watchdog" (WDMinTime > 0) make sure that your first call to wd_triggern is just like all others within the specified time-window. If you call it before WDMinTime is expired, it will not arm the WD, thus the controller keeps running if you never again call the wd_triggern().
When does the WD become "ARMED"?
Upon controller power up, the WD starts counting immediately but remains disarmed until the first flank is toggled, which is done by the function wd_triggern(). However, wd_triggern() will not toggle the WD signal if WDminTime has not yet expired, thus will not arm the WD.
What does config_WD() do?
This function will not trigger or do anything to the WD counter and signal. The settings that were presented with config_WD() will not become affective until a reset has been carried out! Therefore, (see also help file) you need to force the controller to reset with:
//--------------------------------
iStatus = config_wd(&tWatchdog);
if( (iStatus == DATA_CHANGED)||(iStatus == C_CHECKSUM) )
{
wd_reset();
error(); //code should never make it to this line! => error reaction, no reset possible!
}