ESP32 Forum

Hi Everyone,

I faced to a strange problem.

I am developing a product, on some cases, I found even there is no error return, a NVS write cannot really write the new value to the NVS flash. At the same time, I have data logging to the flash too (another partition) and it is also found it cannot work but without flash write error (use partition write api).
1. Is there any accidental possibility to make the flash write protect without returning error? How to know whehther it is invoked the protection and how to return it to normal?
2. If the flash chip on the module is programmed block write protected, why the NVS and flash write returning no error?
3. My application is running at core 1, as usual. And BLE and MQTT (with WiFi) is running at core 0 So I think there may be a potential racing problem of SPI or flash write operation if there is NVS write happened in application and also inside the BLE and MQTT data received callback. Is anyone confirming my understanding is correct?

I am using ESP-IDF V4.4.1

Hello,
1. Yes, flash write protection can sometimes be enabled without returning errors. You can use the API esp_flash_get_chip_write_protect() to check if the flash is write-protected, and esp_flash_set_chip_write_protect() to disable it. Documentation: https://docs.espressif.com/projects/esp ... _flash_tPb

2. I’m not entirely sure in this case. ESP-IDF’s error handling has multiple layers, and may be some protection mechanisms may not propagate errors correctly. Since you’re using IDF v4.4, I’d recommend trying an upgrade to v5.*. You may also try enabling the Kconfig option CONFIG_SPI_FLASH_VERIFY_WRITE to verify that your write operations are successful.

3. You are correct about the possibility of race conditions. ESP-IDF has concurrency controls, but issues can still happen. This document on SPI flash concurrency constraints https://docs.espressif.com/projects/esp ... hatgpt.com may help.
Possible race condition scenarios include:
* Core 0 (BLE/WiFi) and Core 1 (Application) both writing to flash at the same time.
* NVS operations from different cores accessing the same partition.
* Cache invalidation conflicts during flash operations.
To mitigate these, use proper synchronization mechanisms such as mutexes and critical sections around flash operations.

Hello,

Thanks for replying, here are the update:

1. I use esp_flash_get_chip_write_protect() to check the chip write protect, it is always return the chip is protected. I think it is due to the flash chip WE bit in the status register. Seems to me it is not applicable to check the actual write protect status at the chip. Sometimes this problem may be gone once I have a power down and up cycle. I know there are some block protect feature inside a SPI Flash and how can I read those protection status and reset it via ESP API?

2. I make some code to verify the data from reading the data from NVS and compare. I found there is no error return from nvs_commit or nvs_write function, but get different value from reading it after I write, so verify error. Any clue?

3. Thanks, have already moved all NVS write from Core 0 (MQTT callback) to Core 1 (Application), but point 2 still happens at some time.