EEPROM read/write strange behavior.

I’ve been trying to create a “reboot” function for my project, whereby changing a flag will cause EEPROM to reset itself to a default set of values upon next upload. I have managed to get it working, though there is some strange behavior I’ve had to work around;

#include <EEPROM.h>            // Memory control

void setup() {
  Serial.begin(74880);
  while (!Serial) delay(10);
  Serial.setTimeout(250);
  uint8_t MEM_Reboot = 6; // Change to reboot EEPROM.
  Serial.println("MEM_Reboot says " + (String)MEM_Reboot);
  uint8_t MEM_Pulled = EEPROM.read(0);
  Serial.println("Byte 0 says " + (String)MEM_Pulled);
  delay(1000); // Wait a second.
  if (MEM_Reboot != MEM_Pulled) // Rebooting EEPROM?
  {
    Serial.println("Reboot request granted.");
    EEPROM.write(0, MEM_Reboot);    // EEPROM Rebooting.
    // Do some stuff to EEPRPOM
  }
}

void loop() {
}

This code will not work without the imposed 1 second delay right before the if-statement; without this delay MEM_Reboot will read the same as MEM_Pulled regardless of having changed the number before upload, asif EEPROM.write() jumped the line and executed before the code had a chance to execute EEPROM.read(0). It seems the arduino, or the library, does not like having to read and write in quick succession?

Is this behavior expected?

I am using a Wemos Mega, and Arduino IDE 1.8.13

I get the same issue on my Arduino UNO.

Removing the casts to "String" did not help.

Moving the declaration of MEM_Reboot out of setup() to make it a global variable did not help.

Weird. Compiler bug?

I'm in the process of trying to disassemble the hex code to see what the compiler did with it, but it's like pulling nails and honestly its a bit out of my league. :confused:

Apparently there is a required 4ms delay between writes (not sure if the library handles that already), but other than that, it really shouldn't be writing before the code has a chance to read. I've done some trials and it seems it needs at least a 160ms delay to not gag on itself..

Even bypassing the EEPROM library by calling "eeprom_read_byte( (uint8_t*) 0 );" instead of "EEPROM.read(0);" doesn't change the symptom.

Some clever person on Discord has given me a lead to pull; Apparently turning serial on invokes a soft start, so essentially it has run setup() twice by the time it can start outputting its findings to the serial monitor, which of course means the byte has already changed. At Least that is the theory. What do you think?

I think they may be right.

I wrote a sketch that just increments address 0 in EEPROM. If there is a 200-millisecond delay anywhere before writing to EEPROM, it increments by 1 on every upload or reset. If the delay is much less than 200, the Serial Monitor shows some garbled characters before the sketch output and the value increments by 2 on every upload (but not on a manual reset). I think that means that an uploaded sketch runs for about 100+ milliseconds before being reset. If EEPROM is updated in that 100+ milliseconds, the restart sees the updated value.

#include 
void setup()
{
  Serial.begin(115200);
  while (!Serial);
  delay(200);


  uint8_t MEM_Pulled = EEPROM.read(0);
  Serial.print("Byte 0 says ");
  Serial.println(MEM_Pulled);
  
  EEPROM.write(0, MEM_Pulled+1);
}


void loop() {}

Note: If the baud rate is 9600, the 'garbled characters' become readable and you can see the sketch is executed twice on each upload.