ESP32-C6, espidf, error when using components folder, led_strip,h

Development Platforms
,
1

Hi,

I have recently started porting a project to the ESP32-C6. Today I got the followng error which I traced back to an instance of a class that implements the RGB-LED component from espressif.

A fatal error occurred: Contents of segment at SHA256 digest offset 0xb0 are not all zero. Refusing to overwrite.

The issue is also reported on Stackoverflow:

The same class works fine when compiling with the ESP32-C3, so it seems to be related to the C6(?).

2

If the comment in the stackoverflow question is true,

I am getting the same error using the same esp32-c6 board and led-blink-example. I tried a lot of different things but cannot get it to work with PlatformIO

Then please file a bug with Issues · platformio/platform-espressif32 · GitHub.

3

Thanks Max. I filed the report on GitHub and then spent a bit more time looking at the issue. I hope what follows might be useful to anyone with the same problem.

I realised that I have a branch in my repo with a simple rgb_led blink on the Espressif C3 devkit which also uses the same espidf component. When I compiled this for the C6 it worked.

I then went back to my faulty code and manually copied the code from the earlier working example into main.cpp and it compiled, ruling out a fault in the project folder.

Next, I went back to my code and commented almost everything out until the project would compile with the rgb_led class included, then started uncommenting until I found the function that was causing the problem. This turned out to be a function called sleep(), which has as the final line: esp_deep_sleep_start(); Commenting this out, the project compiles, with it uncommented the project gives the error mentioned at the start.

Does anyone have any idea what the connection between the two might be?

4

After quite a bit of discussion (ESP32-C6, espidf, error when using components folder, led_strip,h · Issue #1243 · platformio/platform-espressif32 · GitHub) the problem seemed to lie in the sdkconfig which for some reason contained the incorrect flash size (2MB instead of 8MB). Running pio run -t menuconfig, checking the flash size and saving seemed to solve the problem.