I have a function that performs three adl_flhWrite() calls in a row. Each of these use a different handle and write 4, 4, and 20 bytes respectively. I call this function regularly (i.e. every five minutes for testing).
The ADL documentation says some pretty intimidating things about when the garbage collector fires up. Is my code at risk of causing a watchdog reset when the GC runs? Perhaps I should put adl_ctxSleep(1) calls between each adl_flhWrite() to give control back to firmware?
At the current write rate I expect to invoke the GC in about 16 days so I guess the other option is to just sit back and wait to see if it dies or not.
I’ve wrapped up all my adl_flhWrite() calls inside a Queue and a Timer process. My FlashWrite() pushes the data to a adlQueue, and a timer runs every 50mS - it checks the top of the queue and does the flhWrite() if there’s any data in the queue. Worst case is that it takes 50mS per block of data (so in your case it would take 150mS to write your three blocks). I haven’t had this process trip the watchdog - although I’m only using the flash for configuration data that is changing slowly so I may not have hit the GC either.
Note that the flash endurance is estimated at 100,000 erase/write cycles - so you need to manage the amount of data you are writing.
On the watchdog - I’ve had intermittent issues with some function calls (the A&D flash and WIP among others). It appears that most of the time the operations are fine, but occasionally (randomly?) I’ve called the same code and come out with a watchdog exception. The only thing I can put it down to is that on the occasions that the watchdog exceptions occur, I’ve been unlucky to call my code when the watchdog is nearing the end of it’s counting period and my code trips.
There are some watchdog manipulation functions, and I’ve ended up wrapping some adl functions with my own code that explicitly resets the watchdog before calling the problematic adl functions.