Current FastLED + Arduino ESP32 version 3.3.4 + IDF 5.5.1 + ESP32-C5

[vlad-patoka]

I’m currently trying to bring everything together for ESP32‑C5 support, and I’ve run into several problems.

1. The old ledcAttachPin() + ledcSetup() calls now need to be replaced with the new ledcAttach() API.
2. Bluetooth must be disabled by updating the FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM setting.
3. The Channel Bus Manager is now failing. It used to work reliably, but it currently depends on FL_INIT static constructors, which are not stable under ESP‑IDF and lead to crashes or incomplete initialization.
4. Something has changed in the RMT5 implementation. I’m now seeing RMT memory allocation failures, suggesting that the new approach handles multiple LED strings differently than before. RMT5 previously worked without issues.

I’m trying to move forward with PARLIO, but the latest master branch doesn’t work for me with either PARLIO or RMT5. Earlier versions at least had stable RMT5 behavior and no Channel Bus Manager issues.

[vlad-patoka]

To make some progress - I disabled NetworkDetector. And call initializeChannelBusManager(); directly.
`
// Forward declare the initialization function
namespace fl { namespace detail { void initializeChannelBusManager(); } }

`
It allows me to run FastLED with "RMT" and "SPI"

Then I identified the root cause of the PARLIO memory allocation failure (crash)
parlio_tx_unit_config_t config = {}; // This didn't properly zero-initialize

The issue was improper initialization of the parlio_tx_unit_config_t structure. When the structure wasn't properly zero-initialized, it contained garbage values in memory, particularly:
• trans_queue_depth = 4294967295 (0xFFFFFFFF)
• max_transfer_size = 4294967295 (0xFFFFFFFF)

These garbage values caused the ESP-IDF PARLIO driver to try to allocate a transmission queue with an invalid size of 0xfffffffc (-4), leading to the memory allocation failure.

Added Safety Checks for Division by Zero
// Fixed potential division by zero in buffer calculations if (mState.mDataWidth <= 8 && mState.mDataWidth > 0) { bytes_per_input_byte = 8 * pulses_per_bit / (8 / mState.mDataWidth); } else if (mState.mDataWidth == 16) { bytes_per_input_byte = 8 * pulses_per_bit * 2; } else { // Invalid data width - use safe fallback FL_WARN("PARLIO: Invalid data width " << mState.mDataWidth << ", using fallback"); bytes_per_input_byte = 8 * pulses_per_bit; }

Added Constructor Safety
// Force a valid data width to prevent division by zero if (data_width != 1 && data_width != 2 && data_width != 4 && data_width != 8 && data_width != 16) { FL_WARN("PARLIO: Invalid data_width=" << data_width << " (must be 1, 2, 4, 8, or 16)"); mState.mDataWidth = 1; // ← Added: Force valid value instead of leaving garbage return; }

[zackees]

parlio should now be fixed

I'll look into the other issues

[zackees]

Bluetooth must be disabled by updating the FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM setting.

Clarify

Something has changed in the RMT5 implementation. I’m now seeing RMT memory allocation failures, suggesting that the new approach handles multiple LED strings differently than before. RMT5 previously worked without issues.

RMT5 is introducing worker pools on cooperative async parallel processing, also memory optimization for WIFI being turned on. The ledc actually uses RMT so it needs to handle accounting like your seeing here. ledc is actually the RMT so it's hitting the RMT accounting object to notify it that memory has been taken. Looks like there's a glitch somewhere.

The Channel Bus Manager is now failing. It used to work reliably, but it currently depends on FL_INIT static constructors, which are not stable under ESP‑IDF and lead to crashes or incomplete initialization.

Please elaborate, do you have a stack trace? I'd have a hard time believing that espressif would really not allow static constructor functions. Please provide a stack trace

[zackees]

The old ledcAttachPin() + ledcSetup() calls now need to be replaced with the new ledcAttach() API.

This seems fixed

[zackees]

Re: Bluetooth must be disabled by updating the FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM setting

Claude Code agent here (working on behalf of @zackees). I investigated this issue and need clarification on what specific error you're encountering.

Current State:
FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM is already set correctly in src/platforms/esp/32/drivers/rmt/rmt_5/network_detector.cpp:34:

#define FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM SOC_BT_SUPPORTED

For ESP32-C5, ESP-IDF defines SOC_BT_SUPPORTED = 1 (confirmed in esp-idf/components/soc/esp32c5/include/soc/soc_caps.h), so the macro correctly evaluates to 1.

Why This Is Correct:
ESP32-C5 does have Bluetooth 5 LE hardware. The flag should be 1 so FastLED can:

1. Detect when Bluetooth is active at runtime (NetworkDetector::isBluetoothActive())
2. Adjust RMT memory allocation to tolerate Bluetooth interrupt pressure
3. Prevent RMT buffer underruns when Bluetooth + WiFi are active

What Needs Clarification:
Since you mentioned disabling NetworkDetector as a workaround, I suspect you hit one of these:

1. Compile error - Does #include "esp_bt.h" fail on ESP32-C5 with IDF 5.5.1?
2. Linker error - Does the weak symbol esp_bt_controller_get_status not resolve?
3. Runtime crash - Does NetworkDetector::isBluetoothActive() crash when called?

Can you provide:

• Full compiler/linker error message if it's a build error
• Stack trace if it's a runtime crash
• Your platformio.ini or sdkconfig settings for ESP32-C5

Without this info, I can't determine if this is an IDF 5.5.1 compatibility issue, a missing Bluetooth component, or something else entirely.

[zackees]

I don't see any issue with static constructors. I think you just hit a few bugs when I was deep in a refactor. Please feel free to reopen this bug if i got anything wrong. You should be good to go now.

[vlad-patoka]

The original issue wasn't with FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM itself, but with the conditional compilation logic in network_detector.cpp. The macro was correctly set to SOC_BT_SUPPORTED (which is 1 for ESP32-C5), but the code was trying to include
Bluetooth headers even when Bluetooth was disabled in the project configuration.

Root Cause

#if FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM // This was 1 (hardware supports BT)
#include "esp_bt.h" // But this failed because CONFIG_BT_ENABLED was not set

The logic only checked hardware capability, not whether Bluetooth was actually enabled in the build configuration.

Solution Applied

Modified the conditional compilation in network_detector.cpp to check both hardware capability AND build configuration:

// Before:
#if FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM
#include "esp_bt.h"

// After:
#if FASTLED_RMT_BLUETOOTH_CAPABLE_PLATFORM && defined(CONFIG_BT_ENABLED)
#include "esp_bt.h"

Additional Fixes

1. Added missing component dependencies in FastLED's CMakeLists.txt:

   • esp_mm (for esp_cache.h)
   • esp_wifi and esp_netif (for network detection)

2. Kept network_detector.cpp included (not excluded) since it provides the required NetworkDetector::isAnyNetworkActive() function

Result

• FastLED compiles successfully with ESP-IDF 5.5.2 on ESP32-C5
• Bluetooth detection is properly disabled when CONFIG_BT_ENABLED=n
• WiFi and Ethernet network detection still works
• RMT functionality remains intact

The fix maintains the intended behavior: hardware-capable platforms can detect Bluetooth activity when enabled, but gracefully fall back to stub implementations when Bluetooth is disabled in the project configuration.

Here is other issues. By default I am getting following warnings:

WARN: ChannelBusManager::selectEngine() - No engines registered
WARN: ChannelBusManager::enqueue() - No engines available
WARN: ChannelBusManager::selectEngine() - No engines registered
WARN: ChannelBusManager::enqueue() - No engines available
WARN: ChannelBusManager::selectEngine() - No engines registered
WARN: ChannelBusManager::enqueue() - No engines available
WARN: ChannelBusManager::selectEngine() - No engines registered
WARN: ChannelBusManager::enqueue() - No engines available
WARN: ChannelBusManager::selectEngine() - No engines registered
WARN: ChannelBusManager::enqueue() - No engines available
WARN: ChannelBusManager::selectEngine() - No engines registered
WARN: ChannelBusManager::enqueue() - No engines available
WARN: ChannelBusManager::selectEngine() - No engines registered

So, I have to add:

// Forward declare the initialization function
namespace fl { namespace detail { void initializeChannelBusManager(); } }

and then

// Manually initialize the channel bus manager (FL_INIT not working)
fl::detail::initializeChannelBusManager();

It will call Channel Bus Manager and I am getting following:

src/platforms/esp/32/drivers/channel_bus_manager_esp32.cpp(100): ESP32: Initializing ChannelBusManager with platform engines
src/fl/channels/bus_manager.cpp(52): ChannelBusManager: Added engine 'PARLIO' (priority 100)
src/platforms/esp/32/drivers/channel_bus_manager_esp32.cpp(52): ESP32: Added PARLIO engine (priority 100)
src/platforms/esp/32/drivers/spi/channel_engine_spi.cpp(63): ChannelEngineSpi: Constructor called
src/fl/channels/bus_manager.cpp(52): ChannelBusManager: Added engine 'SPI' (priority 50)
src/platforms/esp/32/drivers/channel_bus_manager_esp32.cpp(69): ESP32: Added SPI engine (priority 50)
src/fl/channels/bus_manager.cpp(52): ChannelBusManager: Added engine 'RMT' (priority 10)
src/platforms/esp/32/drivers/channel_bus_manager_esp32.cpp(89): ESP32: Added RMT5 engine (priority 10)
src/platforms/esp/32/drivers/channel_bus_manager_esp32.cpp(109): ESP32: ChannelBusManager initialization complete

However later, it shows this

src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'PARLIO' (priority 100)
WARN: PARLIO: HAL initialization failed
src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'PARLIO' (priority 100)
WARN: PARLIO: HAL initialization failed
src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'PARLIO' (priority 100)
WARN: PARLIO: HAL initialization failed

Then I enforced to use RMT

// Choose Methods
FastLED.setExclusiveDriver("RMT");

And now its complaining regarding memory allocation:

src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'RMT' (priority 10)
src/platforms/esp/32/drivers/rmt/rmt_5/channel_engine_rmt.cpp(1254): Network state changed: ACTIVE (was: INACTIVE)
src/platforms/esp/32/drivers/rmt/rmt_5/channel_engine_rmt.cpp(1259): Target channel count: 1 (current: 0)
src/platforms/esp/32/drivers/rmt/rmt_5/rmt_memory_manager.cpp(50): RMT Memory (ESP32-C3/C6/H2): TX=96 words, RX=96 words (DEDICATED pools)
src/platforms/esp/32/drivers/rmt/rmt_5/channel_engine_rmt.cpp(1327): Network reconfiguration complete - 0 channels reconfigured

src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'RMT' (priority 10)
WARN: RMT TX channel 1 already allocated
WARN: Memory manager TX allocation failed for channel 1 - insufficient on-chip memory
src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'RMT' (priority 10)
WARN: RMT TX channel 1 already allocated
WARN: Memory manager TX allocation failed for channel 1 - insufficient on-chip memory
src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'RMT' (priority 10)
WARN: RMT TX channel 1 already allocated
WARN: Memory manager TX allocation failed for channel 1 - insufficient on-chip memory
src/fl/channels/bus_manager.cpp(261): ChannelBusManager: Selected engine 'RMT' (priority 10)
WARN: RMT TX channel 1 already allocated

[zackees]

Ping me if this doesn't fix your issue and we can re-open this bug

[zackees]

Okay i think i know what's going on: FL_INIT is being executed in an anon namespace and this might make it a candidate for garbage collection by the linker.

[zackees]

commit d5c4454 fixes the anon namespace issue for FL_INIT