Constant Rebooting - Index < Nitems failed

[jeepers01]

One of my ESP32's failed recently giving the following error no matter what program is flashed to it (successfully)

******************************************
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4
assertion "index >= 0 && index < Nitems" failed: file "/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/nvs_flash/src/compressed_enum_table.hpp", line 38, function: Tenum CompressedEnumTable<Tenum, Nbits, Nitems>::get(size_t) const [with Tenum = nvs::Page::EntryState; unsigned int Nbits = 2u; unsigned int Nitems = 126u; size_t = unsigned int]
abort() was called at PC 0x400d52a3 on core 0

Backtrace: 0x400870fc:0x3ffcb8c0 0x400871fb:0x3ffcb8e0 0x400d52a3:0x3ffcb900 0x40107f4a:0x3ffcb930 0x40108137:0x3ffcb9a0 0x40108459:0x3ffcba00 0x40106d09:0x3ffcba60 0x401069a7:0x3ffcbab0 0x401069f7:0x3ffcbad0 0x400d2e18:0x3ffcbaf0 0x4011bde7:0x3ffcbb10 0x400df16f:0x3ffcbb40

Rebooting...
ets Jun 8 2016 00:22:57

******************************************

Upgraded to Arduino 1.8.4 and reinstalled ESP32 from Github using Git Gui.
Other ESP's are working fine

Any ideas?
Thanks

[ESP_igrr]

Could you please read out the contents of NVS partition using esptool.py read_flash command and attach it here? Once done, you should be able to use erase_flash command in esptool.py to return your device into working state.

[jeepers01]

I couldn't work out how to read_flash but I managed to run erase_flash which cured the problem and it's now working again,
Many thanks for your help ESP_igrr

For the benefit of others this is how I got esptool.py running under Win10
(Already had Python 2.7 installed)
Add ";C:\Python\Scripts" to Windows Comspec
Control Panel > System > Advanced System Settings > Environment Variables
Add at the end of Path ";C:\Python\Scripts"
In Command Prompt(Admin)
C:\>cd Python27\Scripts
C:\Python27\Scripts>pip install esptool
Check in Device Manager which Com Port CP2102 USB TTL UART is on (I'm on 5)
Set ESP32 to boot loader mode (Ground IO0 and press and release Reset)
Then run
esptool.py --port COM5 erase_flash
Which returns
C:\Python27\Scripts>esptool.py --port COM5 erase_flash
esptool.py v2.1
Connecting......
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.1s
Hard resetting...

Hope this helps someone

[thomas.schalch]

Hi

I have the same problem here. As long as the error appears during development, erasing the flash solves the problem. However, if the ESP32 is used in a customer application, the system is "dead" and needs to be replaced, which would be a worst-case scenario...

I've attached a flash dump of the NVS partition. It seems like the NVS has run out of memory, causing these troubles. In my application, it seems to be caused by too much bonded BLE devices.

Is there anything I can do in the application to ...
1. prevent the application from running into this issue?
2. and/or recovering the system, once the NVS partition is "corrupt"?

In some examples in the ESP-IDF, I have seen code like this to initialize the NVS partition:

Code: Select all

    // Initialize NVS
    esp_err_t err = nvs_flash_init();
    if (err == ESP_ERR_NVS_NO_FREE_PAGES) {
        // NVS partition was truncated and needs to be erased
        // Retry nvs_flash_init
        ESP_ERROR_CHECK(nvs_flash_erase());
        err = nvs_flash_init();
    }

However, the system crashes within the nvs_flash_init function. So this code would not help to recover...

Thanks a lot for your help!

[0xffff]

I see this issue when I load firmware developed using idf3.3, and then OTA update using firmware that was developed using idf3.0. It seems that the 3.3 firmware does something that causes the problem when I reload programs created with 3.0 firmware. erase_flash fixes the issue but obviously not a viable solution in the field.