I’m attempting an EEPROM write to all the addresses on an Argon in a for loop. Please see below for the example app. Anyone have any thoughts on why the program seems to freeze in the for loop? The 3rd publish event never fires off in the event stream suggesting that the application is stuck in the EEPROM write loop.
You are requesting EEPROM.length() but then you don’t use that info for your loop count, why?
What is the actual purpose of doing that loop-write?
If you inject a Serial.print() inside the loop you may be able to see where/when the freezing happens.
Hi @ScruffR,
I use that EEPROM.length() just to confirm the corrent length of EEPROM section on the Argon. It’s not meant to be a paradigm statement of how to code the app.
The purpose of that loop-write is to initialize all of the values of the EEPROM addresses to a 0 value. I just read in the reference docs that all the addresses should be initialized to 255 by default, but I’d prefer them all to be 0’s instead.
I’ll try the Serial.print() and post back.
OK, that was eye-opening. I was expecting the EEPROM.put() process to happen as fast as on Gen 3 hardware as it did on Gen 2 hardware. Turns out I was simply not waiting long enough! See below for the code used…
It might be different on Gen3 but when data is stored to flash (this is where EEPROM resides on Gen1&2) then you cannot initialise with 0x00 since that means you cannot write any more bits to that cell an any future write must happen on a new cell which by default will be initialised 0xFF.
Hence my question - I understood what you wanted but I also knew that’s not how things work with flash/EEPROM.
BTW, you could simply use something like this
uint8_t zero[EEPROM.length()];
memset(zero, 0x00, sizeof[zero]);
EEPROM.put(0, zero);
But again - that is a futile endeavour.
@rickkas7 may be able to clarify how the EEPROM implementation works on Gen3, but for Gen1&2 it’s definetly as outlined above.
OK, that’s very informative. To be sure I understand, before a new value can be written to an EEPROM address on gen 1&2 (and maybe 3), the .put command looks for an address with 0xFF before writing a new value? A 0x00 value is not considered “valid” by the .put routine?
Flash can only clear a bit (change 1 -> 0) but never set an individual bit. To set bits (write 1) you need a page earase which will initialise all bits of an entire page with 1.
1 Like
Thanks @ScruffR. Great to know