Keep eeprom values during sketch upload


i know it is not really a blynk related question, but how can i prevent the eeprom being erased every time i upload a new sketch on a wemos d1 mini pro? i store lots of values in eeprom, and it should remain untouched between firmware uploads. i use arduino ide + windoze.

thank you!

Move to SPIFFS rather than using the RTC “EEPROM” area of memory.

oh, ok. i will. but can you elaborate what you mean, please? i never heard about this spiffs thing :slight_smile:

or point me to some link where i can learn…


thanks! :wink:

@Costas, there is still a way to disable eeprom reset while uploading?
i have read throughly the documentation of spiffs, it is nice feature. but i would like to keep my program portable among different mcu boards, and this is not possible if i use heavily spiffs in my code.

Yes if you are using “EEPROM” functions correctly the data will be retained between each sketch upload.

i do not understand what do you mean by using eeprom functions correctly…

i have the eeprom.begin(512);
in the setup,

and i use and eeprom.write + eeprom.commit

is this correct? or should i be aware of some other differences compared with arduino boards?

@Costas, by the time, i have asked on other forums, and they had different opinion:

so, it seems that it is not possible to keep the values in the so called “eeprom” between firmware uploads…

@wanek the comment on the WeMos forum about the flash being completely cleared when a sketch is uploaded is incorrect.

The flash layout is shown below:

^              ^       ^               ^     ^
Sketch    OTA update   File system   EEPROM  WiFi config (SDK)

I must admit I do more with SPIFFS than EEPROM but from the layout it suggests “EEPROM” area will be retained as well as SPIFFS (file system).

See file system (SPIFFS) notes at

hm, i see.
but why it keeps resetting when i upload new sketch?
if i just simply power off / on the wemos, it keeps the values in “eeprom”. but if i upload new sketch, it clears them.

Post your minimum failing sketch and I will take a look at it and dig out one of mine.

SPIFFS for sure will be retained between flashing. I’m a bit curios as to why you would be flashing an ESP which already has data in the EEPROM area of flash.

#include <EEPROM.h>

void setup() {

  EEPROM.write(12, 33);  // comment out next 3 lines after first upload, re upload sketch, and check values.
  EEPROM.write(13, 11);

  Serial.print("eeprom12: ");

  Serial.print("eeprom13: ");

void loop() {}

i’m working on a prototype unit, i store several user settings in the eeprom, they are entered from the blynk app (slider values, etc). as this is a work in progress, i modify a lot the sketch, and i would prefer to have the slider settings saved somewhere, to not re-introduce ~20 values after every upload.

You could save these on the Blynk server and retrieve them on demand i.e. when you reboot / reflash your device.

I will take a look at your sketch but ours is certainly working.
Our “EEPROM” sketch reads some data from Terminal to the EEPROM area and then reboots the device. Depending what the data contains determines which Blynk project is running when the ESP reboots.
We can reflash the ESP and the data in the EEPROM area is unchanged.

When we were looking at EEPROM some months ago we did find that the ESP seems to require different functions to that of a regular Arduino. We built some of our own functions that we posted here on this site but they only contained the following entries:


Our functions (EEPROMgetE and EEPROMputE) can be found at Change auth, ssid and pass from BLYNK terminal for NANO+ESP-01 project - #35 by Costas

Checked your sketch, before commenting out the 3 lines Serial Monitor gives:

eeprom12: 33
eeprom13: 11

after commenting out the 3 lines and reflashing it shows:

eeprom12: 33
eeprom13: 11

Confirms EEPROM area survives a reflash. That was with a WeMos D1 Mini.
Will just check one of my Pro’s now.

Edit: Confirming the Pro works the same as the regular Mini.

Just wondering if you have the right header file. Take a look at as I think it may be different to the Arduino equivalent. Are you using core version 2.3.0 (Jun 23, 2016)?

1 Like

good question… how can i check core version?

Do you have the following in File, Additional Boards Manager urls: ?

If you have this and only this, i.e. without the staging directory, then you should be on 2.3.0 i.e. the last stable release.

Another thing to try is set your board to Generic ESP8266 in the Arduino IDE. We normally use this rather than WeMos as we develop for different ESP’s.

Then maybe track down your EEPROM.h and see if it looks like this:

  EEPROM.cpp - esp8266 EEPROM emulation

  Copyright (c) 2014 Ivan Grokhotkov. All rights reserved.
  This file is part of the esp8266 core for Arduino environment.
  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

#ifndef EEPROM_h
#define EEPROM_h

#include <stddef.h>
#include <stdint.h>
#include <string.h>

class EEPROMClass {
  EEPROMClass(uint32_t sector);

  void begin(size_t size);
  uint8_t read(int address);
  void write(int address, uint8_t val);
  bool commit();
  void end();

  uint8_t * getDataPtr();

  template<typename T> 
  T &get(int address, T &t) {
    if (address < 0 || address + sizeof(T) > _size)
      return t;

    memcpy((uint8_t*) &t, _data + address, sizeof(T));
    return t;

  template<typename T> 
  const T &put(int address, const T &t) {
    if (address < 0 || address + sizeof(T) > _size)
      return t;

    memcpy(_data + address, (const uint8_t*) &t, sizeof(T));
    _dirty = true;
    return t;

  uint32_t _sector;
  uint8_t* _data;
  size_t _size;
  bool _dirty;

extern EEPROMClass EEPROM;


This is not the latest version at but I think that is because there was a commit in August 2016 that is not included in the stable branch dated June 2016.

The location on my machine for the header, which also confirms the core of 2.3.0, for a Windows machine is at:


If you are on Windows just change costas in the path to your Windows username.

ok, i think the board is defective. i found another wemos d1 mini pro, and with the same sketch it is working. i mean the eeprom values are not lost with this new board.

thank for your support!

1 Like

yes, i checked the core version, it is the latest. this will update automatically, or should i check periodically?

It will update automatically when they release a new version. They are busy with the ESP32 core at present.