Reserved eeprom addresses

Hello everyone.

Reference: EEPROM map - #4 by PeteKnight (June '19)
Chip: ESP8266

Hopefully this question is now more relevant to Blynk 1.0.0

Blynk 1.0.0 stores a struct ‘ConfigStore’ (Wi-Fi credentials and setup) in the EEPROM. ConfigStore.h defines the EEPROM_CONFIG_START address as 0

Other than the EEPROM_CONFIG_START address (0) are there any specific EEPROM Addresses that are considered reserved or should now be avoided?

Cheers
Graham

1 Like

Ok, EEProm addresses don’t seem to be on peoples priority list.

My use of the EEProm was prompted by a system that relied upon a small Solar power system and battery for power. It also needs to be able to operate for a week in very cloudy conditions (minimal recharge). I needed to wake the ESP8266, record and send some measurements to the server, then send it to deep sleep for a 5 minute period before starting the next cycle. The EEprom provided a reliable store for the previous readings and could be used to fill in gaps should a sensor return an invalid response - this approach prevented wild swings in received / recorded data.

The issue I encountered with Blynk Inject was that by writing to the EEProm, I was overwriting my Wi-Fi credentials with the obvious consequences. OTA was also very appealing, but of course totally useless when the device is only active for 20 second during every 5 minutes.

The solution is really obvious. Use static provisioning and don’t bother with the EEProm because the previous known good data is stored on the Blynk server and can be easily retrieved.

Doh!
Graham

#define EEPROM_CONFIG_START 0

EEPROM Address is defined in the configstore.h
Try changing the address of your data write. This should solve the issue.

Using EEPROM to store anything other than WiFi credentials is really bad practice.

Each EEPROM location has an expected life of around 100,000 read-write operations, so re-using the same addresses will eventually lead to wear and failure.

That’s why SPIFFS was introduced, but this is now deprecated and replaced with LittleFS.

SPIFFS and LittleFS both operate a proper file system with error checking and lockout tables for faulty memory locations, as well as algorithms to prevent wear of specific addresses.

Pete.