Watchdog

Legacy Legacy AirPrime modules
1

I am getting the following error messages sometimes when my application processes data received on the UART port:

OAT Task Index 2
Watch dog reset: Tsk 32

I’ve also seen Tsk 36, 31, and 29.

The Task index is correct, but I don’t know what the others are. I’m pretty sure the problem is how I’m processing data. I have one task which is mostly copy/paste from the UART example, it has a while(1), eventWait() loop. I have never seen that task ID cause a watchdog reset.

My Task ID 2 has a while(!done) eventWait() loop, and processes data when the event flag is set. This is the task I always crash in. I have tried using adl_wdPut2Sleep(ADL_TMR_S_TO_TICK(60)) to temporarily turn off the hardware watchdog, but this has no effect on the problem.

The flow is:

adl_wdPut2Sleep(ADL_TMR_S_TO_TICK(60));
done = FALSE;
while( !done )
{
     s8 retval;
     u8 character;

     if( serial_dataIsAvailable() == FALSE ) 
     {
             adl_eventWait(dataReadyEvent, READY_TO_PROCESS, ADL_EVENT_WAIT_ALL, timeout);
             //if timeout, then break
     }

     character = serial_getNextChar();
     if( character == ETX ) done = TRUE;
     else doProcessing(character);
}
adl_wdAwake();

The loop only run for a few seconds at a time. Is this really the watchdog resetting the device? If it isn’t, what is the “Watch dog reset error” supposed to mean? I know loops are generally a bad idea here, but I’ve never had a problem with the task that reads the UART data crashing, only task ID 2. Thanks for any help or ideas!

2

Hiya.

while(!done) loops are a killer in the OpenAT environment. Don’t use them. Refactor your code to be an event driven Finite State Machine instead.

Remember that your whole OpenAT application is just another task to the firmware controlling the radio - which is where the TaskID’s you are seeing may be coming from. The Radio Firmware has some very tight constraints to work under when servicing the GSM stack. If the GSM stack is not serviced properly, you run the risk of the GSM network banning your (non-compliant) module from connecting to the network.

Also, there’s no way of knowing just which task is ‘patting’ the watchdog - which is why sometimes a delay of a couple of seconds works, and sometimes doesn’t.

ciao, Dave

3

forum.sierrawireless.com/viewtop … iki#p16098

4

Thanks for the advice. I was hoping my loop struct would be ok, because I’m following the form

while(!done) 
    eventWait()

[url]https://forum.sierrawireless.com/t/faq-forum-wiki/3491/29]

Would this mean that the UART demo is misleading, and putting the hardware watchdog to sleep temporarily doesn’t work?

I’m porting code from our GR64 device, so I’m trying to put off refactoring the entire thing as long as possible, maybe I’m just at that point.

5

But it isn’t, is it?

It is actually of the form

while(!done) 
{
    if( something ) eventWait();
}

So it’s possible that you’re never (or not sufficiently often) hitting the evenWait()…

6

Very true. I never get a reset when I unplug my external device, probably because I’m always waiting for data to become available. I suppose I’m reading enough data in the loop where it never gets a chance to do anything else.

7

Personally I would avoid stalling the watchdog. You can use adl_ctxSleep in the loop to give the watchdog task some breathing space to execute.