WLED
WLED copied to clipboard
ESP32-C6, -C2, -C5, -H2, -P4 are not supported
What happened?
Unable to flash WLED firmware to ESP32-C6-DevKitC-1 v1.1
To Reproduce Bug
Just try to flash wled firmware to any ESP32-C6 chip
Expected Behavior
I guess we need two versions of firmware
Install Method
Binary from WLED.me
What version of WLED?
WLED_0.14.0-b1
Which microcontroller/board are you seeing the problem on?
Other
Relevant log/trace output
[user@user-nvme esp32]$ sudo esptool.py --no-stub write_flash 0x1000 ./esp32_bootloader_v4.bin
esptool.py v4.4
Found 2 serial ports
Serial port /dev/ttyS4
Connecting......................................
/dev/ttyS4 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Serial port /dev/ttyACM0
Connecting...
Detecting chip type... ESP32-C6
Chip is ESP32-C6 (revision v0.0)
Features: WiFi 6, BT 5
Crystal is 40MHz
MAC: 60:55:f9:f6:a2:bc
Enabling default SPI flash mode...
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00010fff...
Erasing flash...
Took 0.29s to erase flash block
Wrote 65536 bytes at 0x00001000 in 0.6 seconds (900.7 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
[user@user-nvme esp32]$ sudo esptool.py --no-stub write_flash 0x10000 ./WLED_0.14.0-b1_ESP32.bin
esptool.py v4.4
Found 2 serial ports
Serial port /dev/ttyS4
Connecting......................................
/dev/ttyS4 failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Serial port /dev/ttyACM0
Connecting...
Detecting chip type... ESP32-C6
Chip is ESP32-C6 (revision v0.0)
Features: WiFi 6, BT 5
Crystal is 40MHz
MAC: 60:55:f9:f6:a2:bc
Enabling default SPI flash mode...
Configuring flash size...
Unexpected chip id in image. Expected 13 but value was 0. Is this image for a different chip model?
A fatal error occurred: ./WLED_0.14.0-b1_ESP32.bin is not an ESP32-C6 image. Use --force to flash anyway
Anything else?
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Correct observation. There are no plans to support C6 at the time as C3, S2 and S3 are still in early experimental phase, not yet ready for production use. And those are older, more mature chips.
Similar for other very brandnew chips: -C2, -C6 , -C61, ESP32-H2, -H4, or ESP32-P4, or -C5.
To put it into some context - market availeability of ESP32-C6 was announced just 3 weeks ago on Jan 6, 2023. Knowing espressif, I bet it will take at least 2 years until stable development environments and open source libraries are ready for any "serious use" on -C6.
We should put it on the backburner, until stable support is availeable from the core libraries we need, for example:
- ESP-IDF
- platformIO espressif32
- arduino-esp32
- see also https://github.com/espressif/arduino-esp32/issues/7713
- NeopixelBus
For now, we have enough troubles to make -S3/-S2/-C3 work. So don't expect support for other new models this year.
Supporting those newer chips requires updating to the esp-idf v5.1. From what I've seen, the migration documentation is pretty good. A potentially valuable bonus is that some of the newer chips, like the S3, now support DMA over the RMT interface. From my experiments, enabling DMA reduces the CPU usage during a transmission to 0.01% compared to about 18% using PIO. I believe this would also reduce the chances of a rogue interrupt causing a glitch proportionally. I'm not sure if this project bumps up into those limits or has a problem with interrupt-caused glitches, but if so, that might be another reason to consider it.
A project as big as WLED needs manpower to support various chips, not just development environment. Any help would be appreciated.
Supporting those newer chips requires updating to the esp-idf v5.1
Sorry, but what you propose is not enough for WLED. We have a long list of dependencies, including (but not limited to) arduino-esp32, and NeoPixelBus.
All dependencies (libraries / frameworks that we use with WLED) need to be upgraded to support new chips. For some (like NPB) explicit support must be added by developing new code. it's not just about dropping in a new framework, then be happy.
I fully concur with @blazoncek - any real help (personal commitment for coding & testing) would be much appreciated.
From what I've seen, the migration documentation is pretty good
Edit: Not sure about quality of the migration document, it is definitely "pretty big" . Espressif announces a huge number of "breaking changes", some important APIs were either deprecated, or already replaced with something completely other. It means a lot of work to go from esp-idf 4.4.x to esp-idf 5.1.
I'm not a user of WLED but also write LED drivers for ESP32, and I'm not making requests, demands or suggestions that you do anything at all. I was sharing information I'd learned about the new features in ESP-IDFv5 that might be relevant to someone else writing LED driver code on ESP chips, since it offers a significant performance improvement. I was excited by my discovery and thought the people working on this project would be too. Your project is impressive and I hope you find the help you're looking for.
Thanks for your willingness to share. Unfortunately we do not write LED (or any other) drivers ourselves but reuse existing @Makuna 's excellent NeoPixelBus.
As such there is (almost) nothing (apart GPIO numbers related stuff) in WLED core code that is chip specific. Libraries as NeoPixelBus or LittleFS and AsyncWebServer are the ones that would need to add support for the above mentioned chips before WLED can support them as well
Though some usermods may use particular HW but those are optional and not all support every chip.
I've been over to the NeoPixelBus repo and looking at Makuna/NeoPixelBus#598 it seems they're already looking into it.