0

I created the below partition table for an esp32 and replaced the 'default_8MB.csv' with it.

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x330000,
app1,     app,  ota_1,   0x340000,0x330000,
eeprom,   data, 0x99,    0x670000,0x1000,
spiffs,   data, spiffs,  0x671000,0x18f000,

After uploading a sketch, I confirmed that the partition table was correctly uploaded to the flash at address 0x8000, using esptool.py --port /dev/ttyACM1 read_flash 0x8000 0x300 partition_table.bin && gen_esp32part.py partition_table.bin && cat partition_table.bin.

Now my question is: what do I have to do so that the EEPROM.h library maps the eeprom emulation to the address that I have specified in the partition table? I naively assumed that EEPROM.h would automatically use the partition named "eeprom", which doesn't seem to be the case.

I uploaded the following test sketch to analyse the situation:

#include <Arduino.h>
#include <EEPROM.h>

String s="this is a unique string";

void setup(){
  EEPROM.begin(1024);

  for (uint32_t i=0;i<s.length();i++){
    EEPROM.write(i,s[i]);
  }
  EEPROM.commit();
  Serial.println("EEPROM stored");
}

void loop() {
  delay(10000);
}

After the sketch has stored my unique string I read the flash memory using esptool and expected to find the string at an offset of 0x670000, but that wasn't the case. Instead it must be stored somewhere else because I can retrieve the string in a different sketch.

One thing that is confusing me: I'm pretty sure that I once ordered ESP-WROOM32s with 4MB flash, but the esptool's auto-flash-detection states that my board has 8MB. Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32? What is supposed to happen if I created a partition table that exceeds the flash memory size? When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).

My main question: which additional steps do I have to take to get my ESP running with a custom_partion_table.csv (beside creating the table) and when using "EEPROM.h"?

  • EEPROM.h looks up the partition location by name. More specifically, it uses the SDK call nvs_open to open the partition named eeprom. So it should be stored at the right location. – Majenko Jan 4 at 11:52
2

EEPROM on the ESP32 doesn't work like you would expect. It uses the SDK's "Non-Volatile Ram" storage system to store the data within the nvs partition. This works through a system of "Key / Value" pairs, and the data is stored as a "BLOB" (Binary Large OBject) for the key eeprom in the namespace eeprom.

Quite what the internal layout of the data within the partition itself is I have no clue (the SDK is closed source), but it won't just have your string located at the start of the partition - it will be at the start of the BLOB, wherever that happens to be in the partition.

The eeprom partition is no longer used. It's just wasted space.

Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32?

I can't comment on that I'm afraid. I would have thought it would look at the chip's JEDEC data, but it may just look at the partition table information instead.

What is supposed to happen if I created a partition table that exceeds the flash memory size?

Probably not a lot, since much of the partition table refers to data storage, or a (presently) unused OTA partition.

When you compile your code you're only compiling it for the partition in which it will reside (app0 for example). When you upload the code you are only uploading to that partition. Anything outside that range is irrelevant to the compilation / uploading.

When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).

As I mentioned, it won't care. The partition will not be accessible, since it doesn't actually exist, but it's just an entry in a table. The compiler doesn't know or care what it is.

| improve this answer | |
  • "it will be at the start of the BLOB, wherever that happens to be in the partition" - until now I had this working the way I expected (the EEPROM structure was just like in my sketch), but unfortunately I had to update the arduino IDE and now the partition scheme I used to work with does no longer exist... How do you upload the eeprom content? – Sim Son Jan 4 at 12:43
  • @SimSon I guess the core changed from manually working with the flash chip to using the SDK's built in system. Makes it simpler for the core to implement, but harder for the user to do low-level stuff. Best to leave EEPROM as internal to the sketch only, and if you want to have data that you can upload from outside a sketch then use SPIFFS. – Majenko Jan 4 at 12:45
  • I'm a bit confused, how do I use "SPIFFS from outside"? What does esptool.py [...] write_flash [...] do (does it depend on the partition type I'm uploading to)? As I understand, I can upload any data to arbitrary memory locations, so what does that have to do with SPIFFS, EEPROM or whatever partition I'd like to write to? On the other hand, what implications does it have to use "SPIFFS from outside"? I seem to lack some important understanding, but I don't know where... – Sim Son Jan 4 at 13:46
  • SPIFFS is a filesystem stored in a flash partition. There are tools to create and manipulate an SPIFFS filesystem image on the computer, which you can then upload to the ESP32 at the correct memory location for your SPIFFS partition. – Majenko Jan 4 at 13:55
  • Sorry, I still don't understand: why can't I simply upload the persistent data (which I'd like to access via EEPROM.h from within the sketch) using the esptool like I did until now? – Sim Son Jan 4 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.