Application reset during recompact

[weiming.chen]

FASTRACK SUPREME 10
ADL SDK 7.3
Application is multitask. Sometimes one task is recompacting, application resets and all the data in A&D are lost. This does not happen everytime.
Has anyone met this kind of problem?
Or any ideas to debug why application reset?
Is there any restrication ablout the recompaction?

[Madouc]

are you checking if you can write to the a&d memory (eg if you get a valid handle)?

[weiming.chen]

Yes, subscribtion and write cell all success.

[BenFT01]

Bit late I guess but I just read this from the ADL User Guide:

Caution: The Garbage Collector process is a time consuming operation. Performing numerous flash write operations in the same event handler increases the probability of Garbage Collector occurence, and should lead to a watchdog reset of the Wireless CPU®. It is not recommended to perform too many flash write operations in the same event handler. If numerous operations are required, it is advised to regularly “give back the hand” to the Firmware (by introducing timers) in the write loop, in order to avoid the Watchdog reset to occur.

if that’s what you mean by recompacting.

[davidc]

Hiya,

When writing to the FLASH (not ADL) storage area, I had to implement a Queue and a timer to do bulk writes so I didn’t trip the watchdog timer.

My reading of the manual is that you can’t do the following (pseudocode):

while(!recompact_done);

i.e a wait loop.

Instead, my understanding is that you have to do it the following way (again, pseudocode):

in the main code:
{
    result=start_compaction();
    start_timer(20ms);
}

in the timer handler:
{
    result=test_compaction_state();
    if (result != recompact_done)
    {
        start_timer(20ms);
    }

Anyway, this is the way that I’ve implemented several long-running operations in my code.

Hope this helps.
ciao, Dave

[awneil]

The A&D Storage API provides events to monitor the progess of the recompaction process…

[BenFT01]

Hummm … I’m getting the random watchdog reset too.
I have a separate task for dealing with the flash write. I wait on a semaphore from the A & D event handler Recompact, then continue. Currently once my buffer is full I do a cell delete / recompact for every new entry which can be every minute. The recompact takes 35 sec!!
THis works most of the time, but every once in a while the watchdog kicks in. THe back trace is somewhere in the recompact process when the watchdog has kicked in. I’m going to try disabling the watchdog during the process to see if that fixes it.

[davidc]

Hiya,

@Ben FT

I’m going to try disabling the watchdog during the process to see if that fixes it.

Note that you can’t completely disable the watchdog - you can only stretch the time required between ‘pats’. By spending a long time in a user application, you run the risk of delaying some operations of the network radio application - which could (in an extreme case) lead to your module falling out of spec and being banned from the Telco’s network.

That said, I share your pain - I’ve had to do this once when scanning an attached I/O network. I’m lucky though - the scan is an infrequent event (usually only at power-on) - so I’ve been lucky so far…

ciao, Dave

[BenFT01]

Well, I’m doing all I can. I used the event driven process, I monitor the progress and print it out so the application is still running. The watchdog reset still occurs occasionally. I disabled the watchdog for 60 seconds and the problem has gone away. The finger is definately pointing at the Wavecom code -->

[davidc]

Hiya,

@Ben FT

he watchdog reset still occurs occasionally. I disabled the watchdog for 60 seconds and the problem has gone away. The finger is definately pointing at the Wavecom code →

Sounds like it’s time to get your distributor onboard to get them to check out your code (and potentially raise an issue with Wavecom).

Let us know how you get on.

ciao, Dave