NVM problem with 0x3000 requirement

[marek406]

Hi everyone,
I’m upgrading to ESP-IDF 5.5 and ran into an issue with the new NVS size requirement.

Context:

• ESP-IDF 5.5 now requires the NVS partition to be at least 0x3000.

• All my already deployed devices use an NVS partition of only 0x2000.

• NVS is used only for system data (e.g., Wi-Fi credentials), so I don’t actually need a larger partition.

• I need both old and new devices to run the same firmware (OTA update).

• I cannot change the partition layout on devices already in the field.

Questions:

• How can I make firmware built with ESP-IDF 5.5 work on devices that still have NVS = 0x2000?

• Is there any way to bypass or override the new minimum NVS requirement?

• If a partition migration is absolutely required, how can it be done safely without bricking legacy devices during OTA?

• What is the recommended workflow for products already deployed, so the upgrade to IDF 5.5 doesn’t require changing the existing partition table?

[lichurbagan]

ESP-IDF 5.5 introduces a hard minimum NVS partition size of 0x3000. This enforcement is done at compile time (Kconfig), link time, and in some cases run time (NVS initialization checks).

[marek406]

Thanks for the clarification.
I’m aware that this issue was introduced in ESP-IDF 5.5 (I mention that in the original post).

My main problem is how to proceed with new firmware when I already have a large number of devices in the field.

If I create a new partition table with NVS ≥ 0x3000, it becomes incompatible with the existing one, meaning the new firmware will not work on already deployed devices. From what I see, there is no safe way to migrate this automatically without breaking compatibility.

So far, I haven’t found a clean solution:

Changing the partition table breaks backward compatibility

OTA migration of the partition table is risky / not straightforward

Maintaining multiple firmware variants (old/new partition layouts) is possible, but feels far from ideal

At the moment, I’m stuck on how this is expected to be handled in real products with deployed devices.
Any recommended migration strategy or best practice would be appreciated.

[ESP_rrtandler]

Hi @marek406 ,

The frimware code using NVS build using IDF 5.5 and later will initialise also from already flashed NVS partitions of the size 0x2000. Even in RW mode. If your newly compiled firmware is built with bigger partition size (i.e. 0x3000), it will still run on devices with partition table (and respective flash layout) having only nvs partition of the size 0x2000. Functions nvs_flash_init* always respect the partition size from flashed partition table and you are not about to change it during OTA.

At the moment, the minimal size of 0x3000 is checked in the "components/partition_table/gen_esp32part.py" (build time) and is defined there as NVS_RW_MIN_PARTITION_SIZE.

In order to pass the build time validation , you can:
1. Increase the size of your nvs partition in respective partitions.csv file. This is from my perspective future proof. You can use the firmware and partition_table.bin (with the larger nvs) to flash brand new devices while using the compiled firmware only to update the in-field devices via OTA. I recommed you to test this approach.
2. Modify the NVS_RW_MIN_PARTITION_SIZE in script. This one allows you to keep all devices with exactly the same partition layout, but the next update of IDF will overwrite this script and you will have to re-patch it.