adl_flhWrite hangs after 292 calls

Legacy Open AT
1

I am writing into one handle which max count is 2000.
Then I do a loop from i=0 to 1999, writing 16 bytes at each ID=i.
The first 292 calls are succesfull (and valid datas can be reread), then my Q2501B hangs.

The data flash remains unusable until I enter a WOPEN=3 command.

If anayone has an idea …

2

Hello,

Some questions basically about the status just before the module hangs… that might give a clue of whats causing the problem…

  1. What does the adl_flhGetFreeMem return just before that last write call?
  2. What is the result code of the last adl_flhWrite call?

/Snoooze

3

Hello,

adl_flhGetFreeMem() returned 111006 and adl_flhGetIDCount returned 2000.

adl_flhWrite returned OK the last time … the next one never returns.

I tried with other capacity ranges (eg 350) and other cell’s size (eg 32, 64 bytes) ; it allways hang.

Philippe

4

Additionaly, I did print before each adl_flhWrite() the result of calls :

  • adl_flhExist() --> allways 0 (cause of my AT+WOPEN=3)
  • adl_flhGetUsedSize( …, 0, i) --> 3796 just before thre hang

Note : the Q25 doesn’t hang forever ; it reboots after 10 seconds then hangs and so one, forever.

5

Could it be possible the reset is caused by the watchdog?

6

Hi pcorgier,
The problem might be due to the fact that flash write operations should not be performed repetitiously in a loop. This is because, each write operation in flash will take some time. Also, some internal processes (like garbage collection) etc will be performed on each write. Hence, as the amount of data in the flash increases, each of these operations (garbage collection etc) will take more and more time.
Hence, as a precaution, you should subscribe to a timer after each call to adl_flhWrite () API and only in the timer handler should you write to the flash again. This will provide enough time to ADL library to perform internal stuff (like garbage collection etc).

When you use a loop to write to flash (instead of using a timer), your Open-AT application will issue adl_flhWrite () APIs to ADL library without any consideration for the time it takes to actually write into flash.
This might cause stack overflow (as now ADL internal functions are in process and your applicaiton still makes calls to adl_flhWrite ()) or may also cause watchdog reset (as OAT is not leaving the CPU).
Hence, it is best to write to flash using a timer when the number of flash objects to write is greater than 100.

Best Regards.

7

I do one write per couple of seconds, called from a timer handler.

After all, I got a new starter kit (because the SIM reader did’nt work) ; since, the flash writing problem doesn’t append any more !

Now a last problem remains : I get ADL_FLH_RET_ERR_NO_ENOUGH_IDS error after 1600 or 2500 writes. The number of successfull writes is very variable.

8

Hi pcorgier,
ADL user Guide specifies that at a timer at the most 2000 object identifiers for flash memory can exist (ADL User Guide, Section 3.5.2).
So, could you please check if your application tries to manipulate object identifiers greater than 2000.
If possible, you can start afresh by erasing all the flash data (by executing AT+WOPEN=3 command) and then observe the behavior.

Usually ADL_FLH_RET_ERR_NO_ENOUGH_IDS is returned if the flash write operation fails due to limitation of number of available IDs.

Best Regards.