# adl\_flhWrite fails for specific ID's

**URL:** <https://forum.sierrawireless.com/t/adl-flhwrite-fails-for-specific-ids/1909>\
**Category:** Open AT\
**Created:** [February 12, 2008, 1:13pm UTC](https://forum.sierrawireless.com/t/adl-flhwrite-fails-for-specific-ids/1909 "2008-02-12T13:13:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tvgeffen](https://avatars.discourse-cdn.com/v4/letter/t/d9b06d/32.png) [@tvgeffen](https://forum.sierrawireless.com/u/tvgeffen)\
**Post date:** [February 12, 2008, 1:13pm UTC](https://forum.sierrawireless.com/t/adl-flhwrite-fails-for-specific-ids/1909/1 "2008-02-12T13:13:22Z")

</div>

Hi All,

I have a Q2501B (firmware 6.50a) which has been running for some time now. When I tried to modify some settings of the device (which are stored in flash) I noticed that the adl\_flhWrite command failed with error -22 (ADL\_FLH\_RET\_ERR\_NO\_ENOUGH\_IDS). I have allocated 200 objects with adl\_flhSubscribe. Some objects now give error -22 when I try to write to them, e.g. #2, #4. Other ID’s still work like #3.

In the FAQ on the main site I found this:

> [@](#):
>
> 1. adl\_flhWrite () API returns -22 (ADL\_FLH\_RET\_ERR\_NO\_ENOUGH\_IDS) when flash object has occupied the maximum limit allocated for it (128 K) or the garbage collector which is called before a flash object is written fails.

So I guess the garbage collector could be the problem, but they don’t mention how it should be fixed.

Has anyone had a similar problem and knows the solution?

Theo

---

<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:** [February 12, 2008, 1:27pm UTC](https://forum.sierrawireless.com/t/adl-flhwrite-fails-for-specific-ids/1909/2 "2008-02-12T13:27:25Z")

</div>

> [@tvgeffen](#):
>
> So I guess the garbage collector could be the problem

Yes, that would seem like a logical conclusion!

> [@](#):
>
> but they don’t mention how it should be fixed.

Unfortunately, you get that with Wavecom documentation. 😠

I think you’ll need to contact your Distributor, and get them to get a response direct from Wavecom?

---

<div class="post-metadata">

**Author:** ![tvgeffen](https://avatars.discourse-cdn.com/v4/letter/t/d9b06d/32.png) [@tvgeffen](https://forum.sierrawireless.com/u/tvgeffen)\
**Post date:** [February 12, 2008, 2:16pm UTC](https://forum.sierrawireless.com/t/adl-flhwrite-fails-for-specific-ids/1909/3 "2008-02-12T14:16:53Z")

</div>

I checked the “bad” id’s with adl\_flhExist and the function returns 0 (object does not exist) for those.

Is it possible to delete specific id’s in the range created with adl\_flhSubscribe? (If not, I guess I discovered some way to do it :p).

I don’t think it’s possible to “recreate” those id’s.

---

<div class="post-metadata">

**Author:** ![optomation](https://avatars.discourse-cdn.com/v4/letter/o/8e8cbc/32.png) [@optomation](https://forum.sierrawireless.com/u/optomation)\
**Post date:** [May 29, 2009, 10:21am UTC](https://forum.sierrawireless.com/t/adl-flhwrite-fails-for-specific-ids/1909/4 "2009-05-29T10:21:01Z")

</div>

I’ve faced this issue too.  
In my case the problem was the size of the object I was willing to write: If it is greater than 30KB, adl\_flhWrite will return the code -22 (ADL\_FLH\_RET\_ERR\_NO\_ENOUGH\_IDS).  
The limit is clearly stated in the documentation of the function. What it is not clear to me is the meaning of the result code, I would expect an ADL\_FLH\_RET\_ERR\_MEM\_FULL instead (or even a new one, more specific).