Watch dog and multiple tasks

Legacy Open AT
1

Hello,
does anybody know how the (hardware) watchdog can be satisfied in a system with multiple tasks, where each task is quite busy?

We’re calling “adl_wdPut2Sleep(ADL_TMR_S_TO_TICK(40))” every 30 seconds. This works for some time, but occasionally the watch dog resets the system.

Does anybody has an idea?

Thanks,
Oliver.

2

Hi
As per your explanation ideally the watchdog reset should not happen.May be the call to adl_wdPut2Sleep is getting missed out somewhere. Are your task event driven?
I am asking this because if the event for the particular task(in which adl_wdPut2Sleep is given) doesnt come then adl_wdPut2Sleep will never be executed and this might be the reason for the watchdog reset.

Regards
Paruthiv

3

Hello,

thanks for your answer. Yes, this task is event driven (a proprietary software timer driven by TCU service and Message service activates the task), but traces show us that the task and adl_wdPut2Sleep() is called in time - even if the watchdog resets the system a few seconds later. Experimentally we implemented “infinite” loops (duration about 30 sec) in various tasks - no problem, OAT is serving the watchdog correctly in the time given by adl_wdPut2Sleep(). Via IO-Pins and oscilloscope I also checked the interrupts - there is no dead lock.

Is it possible, that a software bug somewhere in our application (a bad pointer or something else) could trigger the watchdog?

Thanks,
Oliver.

4

Yes, the watchdog is also triggered by the AT commands at+bug=6 and at+bug=7 of the sample application named Bug.

at+bug=6 trys to call a callback which points on an undefined instruction:

adl_atCmdHandler_t MyHandler = ( adl_atCmdHandler_t ) 0x10000050;
MyHandler ( paras );

at+bug=7 trys to call a callback which points on an undefined address:

adl_atCmdHandler_t MyHandler = ( adl_atCmdHandler_t ) 0x18200000;
MyHandler ( paras );

So we have to de-bug our application. Unfortunately there are no hints in the backtrace :unamused:
Oliver.

5

After removing all C++ exceptions and setting the compiler flag “-fno-exceptions”, the software crashes are gone.

Background: Our project contains Lua with a special Lua scheduler (written in C) and special Lua functions. Lua internally uses setjump/longjump to implement its exception mechanism. Some implementations of C++ exception handling also use setjump/longjump. In particular our Lua scheduler heavily uses the Lua-API and had try-catch blocks (also throw statements). Maybe both setjump/longjump parts didn’t play together perfectly…

Oliver.