adl_adDelete returns -22 !?

cellHandle = adl_adSubscribe ( 0, ADL_AD_SIZE_UNDEF ); // returns OK; ie, 0

result = adl_adDelete( cellHandle );                   // returns -22 !!??

What does -22 mean ?! :open_mouth:

It is not documented! :angry:


I was having the same problem but luckily I’ve found this FAQ: … OS%3A+APIs
There, you can see:
Q: Is there a workaround to solve -22 (ADL_AD_RET_ERROR) being returned from various A&D related APIs (except adl_adSubscribe())?

A: The error -22 (ADL_AD_RET_ERROR) indicates that the A&D storage volume has become corrupt. The workaround to solve this problem is as follows:
i. Subscribe to an A&D storage cell of undefined size.
ii. Without writing anything to the cell, finalize the cell (using adl_adFinalise () API). The return value of this API is not relevant.
iii. Unsubscribe from the subscribed cell.
iv. Call adl_adRecompact () API to Recompact the A&D storage volume.
v. From now onwards, all the A&D related procedures will work fine.

And it worked indeed :stuck_out_tongue:

void commRecompactFinished(void) { }

void Kill22()
  s32 res, fcellh;
  fcellh=adl_adSubscribe(0x100, ADL_AD_SIZE_UNDEF);
  if (fcellh>=0)


So why isn’t this documented in the ADL User Guide?? :angry:

The last recorded change to adl_ad.h is April 2005, and the ADL User Guide for Open-AT v3.03 is dated December 2005 - so even if it was a brand new definition, that should still have allowed plenty of time to get it into the manual! :angry: :angry:


I’ve just realised that I was missing something in the ADL User Guide:

After calling adl_adDelete, the Cell ID does not become available for use again until after the next Recompact.

I think I was probably re-using the Cell ID before a Recompact… :blush:

This does, however, beg the question of why the adl_adSubscribe call didn’t give any error… :unamused:

And there’s still no excuse for the error -22 (ADL_AD_RET_ERROR) being undocumented. :angry:


However, even after fixing this, I have still seen this problem (ADL_AD_RET_ERROR results) occuring.

Note that re-initialising the A&D Volume by calling adl_adFormat does not recover from this situation! :angry:

When the A&D Storage Volume is suffering from this bug, I see adl_adFormat returning -8 (ADL_RET_ERR_BAD_STATE) - ie, it thinks there’s a subscribed cell.