Upgrade platform to 4.4.8 #5357
Conversation
WalkthroughUpdates the ESP32 V4 PlatformIO environment reference, broadens an ESP-IDF version guard in audio code, adds BLE build guidance for the pixels_dice_tray usermod, and removes that usermod's Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
No actionable comments were generated in the recent review. 🎉 Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
from the summary these look like good fixes to have, I have certainly seen my fair share of mysterious crashes due to core issues and am not opposed to any improvement. I am a bit cautious with espressif core issues as they are numerous and really hard to pinpoint (that strange DNS bug from #5332 just to mention one). |
|
Does the changelog say anything about the good-old "I2S left channel swap" bug? Currently AR has the workaround active up to esp-idf 4.4.6 (=arduino 2.0.16), and a year ago i did a short test that confirmed the bug still existed. If the bug still exists, the consequences will be easy to see: make a build with audioreactive included, configure any I2S microphone like the INMP441 or ICS43434. No sound = bug still exists. In that case, extend this guard to include 4.4.8 (or simply change it to match any 4.4.x version) |
|
@coderabbitai does the tasmota framework changelog say anything about the I2S swaped channel bug #5357 (comment) ? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🌐 Web query: 💡 Result: There isn’t a Tasmota For the ESP32/I2S changes around that time window, the relevant entry is in Tasmota v14.1.0 (“Rachel”), which lists “ESP32 I2S audio improvements” (PR #21433) while the ESP32 platform at that point is noted as Core3 platform Sources: 🌐 Web query: 💡 Result: ESP-IDF v4.4.8 (legacy Fix / workaround in ESP-IDF 4.4.8
So if you assumed the opposite wiring, it will appear “swapped” unless you re-route accordingly (or swap channels in software). Sources: Citations:
🌐 Web query: 💡 Result: I couldn’t find any published Arduino-ESP32 2.0.17 → 2.0.18 release-note item (or tracked PR/issue) that specifically says it fixes swapped I2S L/R channels—and the public GitHub “Releases” page content that’s readily accessible today mostly shows newer 3.x releases, not the old 2.0.18 notes. [1] What you can do on 2.0.17 / 2.0.18 if your DAC output is L/R swapped:
Related: ESP-IDF docs also call out that some I2S data can appear “swapped” in certain mono/buffer-format cases (different problem than L/R stereo, but it often gets confused with “channel swap”). [3] And historically, people have observed L/R swap behavior with certain ESP-IDF baselines (e.g., PlatformIO note about IDF v4.0). [4] If you share:
Sources: 🏁 Script executed: Length of output: 367 🏁 Script executed: Length of output: 14553
Key findings:
Recommendation: Your suggestion to extend the guard is correct. You should either:
As you mentioned, this can be verified by testing with an I2S microphone (INMP441 or ICS43434) – if there's no sound with the audioreactive build, the bug still exists and the workaround must be extended. 🧠 Learnings used |
It's very unlikely that this old bug will ever be fixed in any esp-idf 4.4.x release.
|
@netmindz I've extended the workaround. |
| */ | ||
|
|
||
| #if (ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(4, 4, 0)) && (ESP_IDF_VERSION <= ESP_IDF_VERSION_VAL(4, 4, 6)) | ||
| #if (ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(4, 4, 0)) && (ESP_IDF_VERSION < ESP_IDF_VERSION_VAL(4, 5, 0)) |
|
The change log sounds very good indeed. Espressif basically "dropped the pen" on the 2.0.17 code in summer 2024, exactly at the moment when official support ran out. That's one of the reasons I never wanted plain 2.0.17. Plus I'm a bit cautious in general about espressif code, same as @DedeHai. But let's give it a chance 😀 maybe the tasmota team managed to finish the job that espressif failed to do. |
|
I gave it a spin and did not notice any immediate oddities. It saves quite a lot of flash: 20k on the C3 and 17k on the ESP32 classic. RAM usage is different though: 2.4k saved on the C3, an addtional 1k used on the ESP32. Did not check S2 and S3. DNS queue (#5332) and WiFi scan (#5351) bugs are not fixed unfortunately. |
3 participants
Summary of Changes: v4.4.5 → v4.4.8
🔴 High Impact for WLED
1. Wi-Fi Stability & Connectivity
This is the single biggest area of improvement and directly impacts WLED's core functionality:
esp_wifi_scan_startmemory leakage, fixed beacon timeout after restart, fixed Wi-Fi stop taking too long in coexistence scenarios, fixed station no response after "m f null", fixed PSRAM causing DHCP failure in WAPI encryption mode, fixed AMPDU duration issuesesp_wifi_stop, fixed scan-while-connected causing loop beacon timeout, fixed WPA3-SAE memory leak, patched CVE-2023-52160 (PEAP authentication vulnerability)2. BLE Coexistence Fixes
WLED supports ESP-NOW and can run alongside BLE:
3. Ethernet Fixes
WLED supports Ethernet via
esp32_ethbuild environments:🟡 Medium Impact for WLED
4. PSRAM Fixes (ESP32-S3 with PSRAM boards)
5. RMT Driver Fix
6. Power Management & Sleep
7. NVS (Non-Volatile Storage) Fixes
nvs_get_blobwith inconsistent multi-page BLOBs8. Heap & Memory Management
🟢 Lower Impact but Notable
9. Security Fixes
10. Peripheral Driver Fixes
Summary & Recommendation
Category | Fixes (4.4.4→4.4.8) | WLED Relevance -- | -- | -- Wi-Fi | ~40+ fixes including "m f" crash, memory leaks, security CVEs | Critical BLE/Coexistence | ~80+ fixes across BLE controller, host, and coex | High (ESP-NOW, audioreactive) Ethernet | EMAC hang, buffer errors, PHY timing | High (Ethernet builds) PSRAM | Timing, detection, sleep interaction fixes | High (S3 PSRAM builds) Heap/Memory | 40% footprint reduction, crash fixes | Medium-High NVS | Race condition, buffer overrun | Medium Security | mbedTLS updates, CVE patches | Medium Sleep/Power | Multiple current and wakeup fixes | Medium Peripherals | I2C, LEDC, ADC, RMT fixes | Low-MediumSummary of Changes: v4.4.5 → v4.4.8
🔴 High Impact for WLED
This is the single biggest area of improvement and directly impacts WLED's core functionality:
v4.4.5: Fixed KRACK key reinstallation vulnerabilities (CVE-2017-13077 through CVE-2017-13082), fixed station connecting slowly to some APs, fixed modem sleep issues after scan
v4.4.6: Fixed SoftAP not verifying SSID of association requests, fixed Wi-Fi MAC not going to sleep, fixed beacon parsing with zero-length IEs
v4.4.7: Fixed esp_wifi_scan_start memory leakage, fixed beacon timeout after restart, fixed Wi-Fi stop taking too long in coexistence scenarios, fixed station no response after "m f null", fixed PSRAM causing DHCP failure in WAPI encryption mode, fixed AMPDU duration issues
v4.4.8: Fixed ESP32 unrecoverable "m f" issue, fixed AMPDU compatibility for some APs, fixed task watchdog triggered by esp_wifi_stop, fixed scan-while-connected causing loop beacon timeout, fixed WPA3-SAE memory leak, patched CVE-2023-52160 (PEAP authentication vulnerability)
WLED impact: Many users report Wi-Fi disconnection and connectivity issues (#4187). The "m f" fix alone is significant — this was a well-known unrecoverable crash on ESP32. Memory leaks in scan and WPA3 would affect WLED devices that reconnect frequently.
WLED supports ESP-NOW and can run alongside BLE:
v4.4.5-4.4.8: Dozens of fixes for BLE+WiFi coexistence crashes, including fixed scan not restarting after WiFi interruption, fixed coexistence assert on ESP32, fixed memory leaks when BLE scan and other events coexist
v4.4.8: Fixed circular dependency issue on ESP32 coexistence, fixed loss of coexistence request events causing BT link disconnection
WLED impact: Users running audioreactive (which uses I2S/DMA) alongside WiFi would benefit. ESP-NOW stability would improve.
WLED supports Ethernet via esp32_eth build environments:
v4.4.6: Fixed ESP32 EMAC hang when stopped/started multiple times at 10Mbps, fixed Ethernet transmit when link was down
v4.4.7: Reduced "no mem for receive buffer" errors (multiple longstanding issues fixed)
v4.4.8: Fixed IP101 reset timing to align with datasheet
WLED impact: Directly relevant to #4502 (Fix Ethernet builds with V4). The EMAC hang and receive buffer fixes would improve Ethernet reliability.
🟡 Medium Impact for WLED
4. PSRAM Fixes (ESP32-S3 with PSRAM boards)
v4.4.5: Fixed Octal PSRAM detection on ESP32-S3, fixed PSRAM timing tuning for 80MHz Octal PSRAM
v4.4.6: Fixed SPI Flash concurrency under XIP_PSRAM, fixed Octal PSRAM timing tuning under low temperature on ESP32-S3
v4.4.7: Fixed PSRAM access failure after CPU-powered-down light sleep wakeup, fixed PSRAM crash due to wrong MSPI timing after frequency switching with DFS
WLED impact: WLED's ESP32-S3 builds with PSRAM (esp32s3dev_16MB_opi, esp32s3dev_8MB_opi) would directly benefit. WLED uses PSRAM for JSON buffers and LED data on S3 boards.
RMT Driver Fix
v4.4.5: Fixed some RMT LL functions not being inlined
WLED impact: WLED uses RMT for NeoPixel LED output, including a custom high-priority interrupt RMT driver (NeoEsp32RmtHIMethod). Inlining fixes could slightly improve LED output performance.
Power Management & Sleep
v4.4.6-4.4.8: Multiple sleep current fixes, fixed light sleep wakeup failures, fixed Fast/Slow memory loss in sleep on C3/S3, fixed watchdog timeout after light sleep wakeup
WLED impact: Users running WLED on battery-powered projects or with sleep features would see improvements.
NVS (Non-Volatile Storage) Fixes
v4.4.8: Fixed race condition during NVS Lock initialization, fixed buffer overrun in nvs_get_blob with inconsistent multi-page BLOBs
WLED impact: WLED stores settings, presets, and configuration in NVS. The buffer overrun fix is a potential crash/corruption fix.
Heap & Memory Management
v4.4.5: Heap component binary IRAM/DRAM usage decreased by ~40%, added better failure logging
v4.4.7: Added memory poisoning checks for integrity functions
v4.4.8: Fixed heap_caps_calloc size propagation to allocation failed hook
WLED impact: WLED is often heap-constrained. The 40% reduction in heap component footprint could free up valuable IRAM/DRAM. WLED has custom d_malloc/d_calloc wrappers that enforce minimum free heap.
🟢 Lower Impact but Notable
9. Security Fixes
v4.4.5: eFuse key burning bug fix for ESP32-C3/S3
v4.4.6: Hardware AES DMA descriptor memory corruption fix
v4.4.7: Anti-rollback security bypass protection, mbedTLS updated to 2.28.7
v4.4.8: mbedTLS updated to 2.28.8, CVE-2023-52160 (PEAP auth), CVE-2024-24746 (NimBLE DoS)
WLED impact: Important if WLED is deployed on networks requiring enterprise authentication or if using secure boot.
I2C timeout fix (v4.4.8) — relevant for WLED I2C usermods (4-line display, sensors)
LEDC PWM 100% duty cycle fix (v4.4.7) — relevant if using PWM-based LED drivers
ADC oneshot mode fixes — relevant for audioreactive analog input
SDMMC card initialization fixes — relevant for file-based presets stored on SD cards
Summary & Recommendation
Category Fixes (4.4.4→4.4.8) WLED Relevance
Wi-Fi ~40+ fixes including "m f" crash, memory leaks, security CVEs Critical
BLE/Coexistence ~80+ fixes across BLE controller, host, and coex High (ESP-NOW, audioreactive)
Ethernet EMAC hang, buffer errors, PHY timing High (Ethernet builds)
PSRAM Timing, detection, sleep interaction fixes High (S3 PSRAM builds)
Heap/Memory 40% footprint reduction, crash fixes Medium-High
NVS Race condition, buffer overrun Medium
Security mbedTLS updates, CVE patches Medium
Sleep/Power Multiple current and wakeup fixes Medium
Peripherals I2C, LEDC, ADC, RMT fixes Low-Medium
Summary by CodeRabbit
Chores
Documentation
Part 2: Arduino Core 2.0.9 → 2.0.17 Changes
Arduino Core 2.0.18 does not exist. The 2.x line ended at v2.0.17 (May 2024, based on ESP-IDF 4.4.7). The next release was v3.0.0 (May 2024, based on ESP-IDF 5.1.4), which is a major breaking change.
v2.0.17 (May 2024) — based on ESP-IDF 4.4.7
Fixed HWCDC firmware uploading — important for USB-CDC flashing on ESP32-S3/C3
Arduino Nano ESP32 board fix
v2.0.10 through v2.0.16
WLED explicitly warns against 2.0.10 through 2.0.14 in platformio.ini ("buggy so avoid them")
These versions introduced various regressions that affected stability
Summary of what changed between 2.0.9 and 2.0.17:
The primary change is the underlying ESP-IDF version moving from 4.4.4 to 4.4.7, carrying all the fixes described in Part 1 above.
Part 3: Impact Assessment for WLED
🔴 Critical Impacts (Stability/Crashes)
Xtensa register corruption fix (4.4.7) — Random crashes from a6/a7 register corruption during task context switching. WLED is heavily multitasked, so this is very relevant.
SPI Flash concurrency fix (4.4.6) — Could cause flash corruption when using PSRAM (many S3 builds).
AES DMA memory corruption (4.4.6) — Could cause crashes when using encryption (HTTPS/TLS).
esp_timer linked list corruption (4.4.6) — Could cause random crashes; WLED uses timers extensively.
🟠 High Impacts (WiFi/Networking)
WiFi fixes across all three versions — Beacon timeout, scan failures, modem sleep, fragment handling, DHCP, multicast. WLED's core functionality depends on WiFi.
LwIP fixes — TCP out-of-order handling, DHCP server subnet overflow, multicast forwarding. Directly affects E1.31, Art-Net, DDP protocols.
mDNS fix — WLED uses mDNS for device discovery.
🟡 Medium Impacts (Peripheral/Feature)
LEDC duty cycle 100% fix (4.4.7) — Directly affects WLED's analog (PWM) LED output. Previously couldn't reach full brightness.
I2S channel format/mono mode fixes — Affects audio-reactive WLED builds.
ADC clock divider fixes — Affects audio-reactive microphone input accuracy.
Ethernet fixes — Important for Ethernet-enabled WLED controllers (e.g., WT32-ETH01, QuinLED-ESP32).
UART fixes — Could affect DMX input/output.
Heap improvements — ~40% reduction in heap component IRAM usage; important since WLED is memory-constrained.
PSRAM timing fixes for ESP32-S3 — Better stability on S3 boards with OPI PSRAM.
USB Serial JTAG data loss fixes — Affects S3/C3 boards using USB-CDC for serial communication.
🟢 Recommendation
Upgrading from ESP-IDF 4.4.4 (Arduino Core 2.0.9) to ESP-IDF 4.4.7 (Arduino Core 2.0.17) would bring significant stability, security, and performance improvements to WLED. The most impactful areas are:
Random crash prevention (register corruption, timer corruption, flash concurrency)
WiFi reliability (dozens of fixes across 3 releases)
Analog LED output (LEDC 100% duty cycle fix)
Memory efficiency (heap IRAM savings)
ESP32-S3 stability (PSRAM, SPI flash, USB-CDC fixes)
However, WLED's note about Arduino Core 2.0.10-2.0.14 being "buggy" suggests that some intermediate versions had regressions. Moving directly to 2.0.17 (or the very latest 2.0.17 Tasmota fork) would be the safest path, skipping the problematic intermediate versions.
Alternatively, the project could consider moving to Arduino Core 3.x (ESP-IDF 5.x), but that's a much larger migration with breaking API changes across WiFi, BLE, GPIO, LEDC, and more (see the Migration Guide from v2.X to 3.X).