[ESP32-S3] Lost WiFi configuration in NVS after OTA due to Partition Table error?

[Huy_Tran_DF]

Hi everyone, I'm having a strange problem with NVS on my ESP32-S3 (16MB Flash) running ESPHome (ESP-IDF) and I need advice from experts on Memory Mapping

Problem: I performed an OTA firmware update. The OTA process was successful, and the device booted to the correct new version. HOWEVER, all WiFi credentials (SSID/Password) stored in NVS were lost, causing the device to fall into Fallback AP mode. Strangely, the NVS data I saved myself (custom key/value) is still there; only the system WiFi is gone
Partition configuration: I suspect the problem is that my partitions.csv file doesn't have any spaces (gaps)

Code: Select all

# Name,   Type, SubType, Offset,  Size, Flags
otadata,  data, ota,     0x9000,  0x2000,
phy_init, data, phy,     0xb000,  0x1000,
app0,     app,  ota_0,   0x10000, 0x400000,
app1,     app,  ota_1,   0x410000,0x400000,
nvs,      data, nvs,     0x820000,0x6d000,

Code: Select all

app1 (OTA Partition): Terminates at address 0xF90000.

nvs: Starts immediately at address 0xF90000.

Hypothesis: From what I've researched, it seems to be due to the Flash erase mechanism (4KB sector erase). When the OTA erases the App partition to write new code, it accidentally erases the first sector of the NVS (because they are close together), damaging the NVS Wifi header.

Question: Is it mandatory to leave a gap (e.g., 64KB) between the App partition and the NVS partition to avoid this error? Or is there another cause?

Thanks everyone!

[ESP_rrtandler]

Hi @Huy_Tran_DF ,

There is definitely no need to create a gap between the end of the app partition and subsequent nvs partition.

From your post, it is not obvious, whether the OTA updated (ESP_Home) application was built using the same version of IDF as the initial one. If it is was the case, there might be a difference in data set used by the WiFi subsystem in NVS. Wifi credentials and other information is stored in the namespace nvs.net80211 in NVS as individual keys. Different versions of IDF can save different number of keys and the WiFi library tries to apply data recovery and defaulting when it detects incomplete or incompatible set of NVS data.

You can try to list all keys from the NVS namespace nvs.net80211 when old version of software is uploaded and STA connected and then list the keys from the same namespace when running the new version of the application and it is connected to STA.

To get the content of the NVS partition from ESP32, you can use:
python parttool.py -p PORT -b BAUD read_partition --partition-name nvs --output nvs.bin

To show the partition content of the NVS partition, you can use:
python $IDF_PATH/components/nvs_flash/nvs_partition_tool/nvs_tool.py dump nvs.bin