NVS component tries to retrieve data from the APP (should be in NVS data) partition with guids to invalit argument in esp_partition_read() (IDFGH-11823)

[ralphde]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

5.x

Espressif SoC revision.

ESP32-S2

Operating System used.

Windows

How did you build your project?

Eclipse IDE

If you are using Windows, please specify command line type.

None

Development Kit.

custom

Power Supply used.

External 5V

What is the expected behavior?

that values stored in NVS can be retrieved from any task at any time.

What is the actual behavior?

The purpose is to store and read a simple unsigned log variable stored in NVS. While the Wifi component are able to read and write is it impossible for my application to read the variable from the HTTP server component task.

And this is how a call should look

Steps to reproduce.

create a NVS variable in the main task and read it from anywhere

Debug Logs.

see screen shots

More Information.

I have sacrificed my Christmas and new years eve to find a solution, no chance. The whole problem started when I set up a new computer for developing with no ties to former installed IDF versions. On my old computer, where the .espressife folder contained other IDF tools it worked miraculously using IDF 5.0.2 until I started to use a clean new computer. And now I introduced the habit to delete the .espressife folder when I change the IDF version and this issue is persistent now

This behavior is so bad, that I thing any IDF 5.x is not usable at all because I have also the problem that simple global variables are not accessible from other tasks scopes. I had to store all those in the heap.

[pacucha42]

Hi @ralphde, thank you for the report.
Could you share code, please? The troublesome parts would be sufficient. NVS component uses its own partition type and should be accessed purely by the NVS interface (no esp_partition_read()). Generally, the access should be independent on OS task type.

[ralphde]

I have submitted the code to Jakob in #12711 let me know if you can retrieve it there. If not disclose private email please, the issue occurs in our special use case and can not produced isolated. Best Regards Mit freundlicher Empfehlung Ralph Deffke Am Mo., 8. Jan. 2024 um 09:18 Uhr schrieb pacucha42 < ***@***.***>:

…

Hi @ralphde <https://github.com/ralphde>, thank you for the report. Could you share code, please? The troublesome parts would be sufficient. NVS component uses its own partition type and should be accessed purely by the NVS interface (no esp_partition_read()). Generally, the access should be independent on OS task type. — Reply to this email directly, view it on GitHub <#12916 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADL5WF3GFXHHC2GWR6MVT2TYNOTUFAVCNFSM6AAAAABBJ6YS5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGU2DQMJXG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pacucha42]

Ok, will take a look. Thanks!

[ralphde]

Just FYI I had to go back to 4.4.6. It works seamlessly in production since about a year. Just in any 5.x version nothing works. Best Regards Mit freundlicher Empfehlung Ralph Deffke Am Mo., 8. Jan. 2024 um 09:57 Uhr schrieb pacucha42 < ***@***.***>:

…

Ok, will take a look. Thanks! — Reply to this email directly, view it on GitHub <#12916 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADL5WF4DYCXDYFJUYFJT3M3YNOYG3AVCNFSM6AAAAABBJ6YS5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGU4TOOJVGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pacucha42]

Source code attachment found, I'll update you asap. Thank you

[AxelLin]

Source code attachment found, I'll update you asap. Thank you

@pacucha42 Any update?

[rrtandler]

Hi @AxelLin and @ralphde,

Please try to avoid second call to nvs_flash_init. The current source code does the sequence:
main.c -> maxill_name.c:fileNameInit() -> nvs_flash_init();
main.c -> maxill_name.c:fileNameInit() -> nvs_open(... &maxill_nvs_handle);
main.c:ESP_ERROR_CHECK(nvs_flash_init());

Second call to nvs_flash_init in main.c likely invalidates the maxill_nvs_handle obtained in the fileNameInit()

You can try to comment the "main.c:ESP_ERROR_CHECK(nvs_flash_init());" line as the nvs_flash is already initialized by the fileNameInit().

[rrtandler]

I am closing the issue as there is no update for a long period of the time. Please free to reopen if you feel the problem persists.