# Application reset during recompact

**URL:** <https://forum.sierrawireless.com/t/application-reset-during-recompact/3085>\
**Category:** Open AT\
**Created:** [April 1, 2009, 10:42am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085 "2009-04-01T10:42:51Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![weiming.chen](https://avatars.discourse-cdn.com/v4/letter/w/4bbf92/32.png) [@weiming.chen](https://forum.sierrawireless.com/u/weiming.chen)\
**Post date:** [April 1, 2009, 10:42am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/1 "2009-04-01T10:42:51Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Madouc](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Madouc](https://forum.sierrawireless.com/u/Madouc)\
**Post date:** [April 1, 2009, 1:58pm UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/2 "2009-04-01T13:58:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![weiming.chen](https://avatars.discourse-cdn.com/v4/letter/w/4bbf92/32.png) [@weiming.chen](https://forum.sierrawireless.com/u/weiming.chen)\
**Post date:** [April 3, 2009, 1:54am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/3 "2009-04-03T01:54:03Z")

</div>

Yes, subscribtion and write cell all success.

---

<div class="post-metadata">

**Author:** ![BenFT01](https://avatars.discourse-cdn.com/v4/letter/b/73ab20/32.png) [@BenFT01](https://forum.sierrawireless.com/u/BenFT01)\
**Post date:** [May 19, 2009, 4:37pm UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/4 "2009-05-19T16:37:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![davidc](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@davidc](https://forum.sierrawireless.com/u/davidc)\
**Post date:** [May 19, 2009, 10:41pm UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/5 "2009-05-19T22:41:38Z")

</div>

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):

```auto
while(!recompact_done);
```

i.e a wait loop.

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

```auto
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

---

<div class="post-metadata">

**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\
**Post date:** [May 20, 2009, 4:30am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/6 "2009-05-20T04:30:12Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![BenFT01](https://avatars.discourse-cdn.com/v4/letter/b/73ab20/32.png) [@BenFT01](https://forum.sierrawireless.com/u/BenFT01)\
**Post date:** [July 24, 2009, 2:32pm UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/7 "2009-07-24T14:32:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![davidc](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@davidc](https://forum.sierrawireless.com/u/davidc)\
**Post date:** [July 26, 2009, 12:55am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/8 "2009-07-26T00:55:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![BenFT01](https://avatars.discourse-cdn.com/v4/letter/b/73ab20/32.png) [@BenFT01](https://forum.sierrawireless.com/u/BenFT01)\
**Post date:** [July 27, 2009, 8:47am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/9 "2009-07-27T08:47:56Z")

</div>

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 --\>

---

<div class="post-metadata">

**Author:** ![davidc](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@davidc](https://forum.sierrawireless.com/u/davidc)\
**Post date:** [July 27, 2009, 10:52am UTC](https://forum.sierrawireless.com/t/application-reset-during-recompact/3085/10 "2009-07-27T10:52:12Z")

</div>

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
