Fixed bug of ESP32 crashing when using DMX out #5316

coderabbitai · 2026-04-28T12:02:54Z

⚠️ Potential issue | 🟠 Major

Fix the read-path indexing.

read(1) currently returns dmxData[0], which is the start code, so every DMX channel is shifted down by one. If the API is 1-based, this should read from dmxData[Channel] instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed. In `@wled00/src/dependencies/dmx/SparkFunDMX.cpp` around lines 123 - 124, The read-path is off by one: the start code lives in dmxData[0] so a 1-based API should return dmxData[Channel] not dmxData[Channel - 1]; update the read(Channel) logic to use dmxData[Channel] and adjust the bounds check to ensure Channel is within 1..(chanSize-1) (or otherwise ensure chanSize represents the highest valid 1-based channel index), referencing the read function, Channel parameter, chanSize and the dmxData buffer when making the change.

coderabbitai · 2026-01-24T17:11:08Z

⚠️ Potential issue | 🟠 Major

Off-by-one error in bounds check allows potential buffer overflow.

In write mode, chanSize = chanQuant + 1. When chanQuant = 512 (max), chanSize = 513. The check Channel > chanSize evaluates Channel > 513, which allows Channel = 513 to pass, resulting in dmxData[513] — an out-of-bounds write (array indices are 0–512).

Proposed fix

void SparkFunDMX::write(int Channel, uint8_t value) { - if ((Channel < 1) || (Channel > chanSize)) return; + if ((Channel < 1) || (Channel >= chanSize)) return; dmxData[Channel] = value; //start byte at dmxData[0] }

Based on learnings, in WLED the priority is to prevent out-of-bounds memory access.

🤖 Prompt for AI Agents

In `@wled00/src/dependencies/dmx/SparkFunDMX.cpp` around lines 129 - 132, The write method in SparkFunDMX::write has an off-by-one bounds check allowing Channel == chanSize which writes past the end of dmxData; update the condition to reject Channel values >= chanSize (i.e., ensure valid Channel is 1..chanSize-1) so accesses to dmxData[Channel] cannot overflow; modify the check that currently uses (Channel > chanSize) to use (Channel >= chanSize) (referencing SparkFunDMX::write, Channel, chanSize, chanQuant and dmxData).

@coderabbitai is this off-by-one error already present in the previous code, or was it introduced by changes in this PR?

@softhack007, the off-by-one error is newly introduced by this PR.

Previous code behavior:
The old code had a different bug:

if (Channel > chanSize) chanSize = Channel; // BUG: swaps/corrupts chanSize variable dmxData[Channel] = value;

When Channel > chanSize, it would incorrectly modify chanSize itself (the variable swap bug mentioned in the PR description), then proceed to write to dmxData[Channel]. This could corrupt the chanSize variable and potentially write out of bounds.

New code behavior:
The PR fixes the variable swap bug by adding a bounds check and early return. However, the check has an off-by-one error:

if ((Channel < 1) || (Channel > chanSize)) return; // Allows Channel == chanSize dmxData[Channel] = value;

Since chanSize = chanQuant + 1 (line 117) and max chanQuant = 512, we get chanSize = 513. The condition Channel > 513 allows Channel = 513 to pass, accessing dmxData[513], which is out of bounds (valid indices: 0–512).

The fix I suggested (Channel >= chanSize) would properly reject Channel = 513 and ensure only valid channels 1–512 can write to array indices 1–512, while index 0 remains the start byte.

🧠 Learnings used

Learnt from: mval-sg Repo: wled/WLED PR: 4876 File: wled00/xml.cpp:0-0 Timestamp: 2025-08-28T08:09:20.630Z Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

Learnt from: mval-sg Repo: wled/WLED PR: 4876 File: wled00/wled_eeprom.cpp:0-0 Timestamp: 2025-09-01T10:26:17.959Z Learning: In WLED PR `#4876`, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.

Learnt from: DedeHai Repo: wled/WLED PR: 4926 File: wled00/FX.cpp:4727-4730 Timestamp: 2025-11-16T19:40:46.260Z Learning: WLED AuroraWave (wled00/FX.cpp): wave_start and wave_end intentionally use int16_t; segments longer than 32k LEDs are not supported (bounded by MAX_LEDS), so widening to 32-bit is unnecessary.

Learnt from: DedeHai Repo: wled/WLED PR: 4997 File: wled00/e131.cpp:33-44 Timestamp: 2025-10-10T18:34:06.550Z Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

Learnt from: BobLoeffler68 Repo: wled/WLED PR: 5109 File: wled00/FX.cpp:3174-3343 Timestamp: 2025-11-27T06:33:11.436Z Learning: WLED Ants effect (wled00/FX.cpp): The author prefers the current velocity initialization using hw_random16(1000, 5000)/5000.0f, resulting in an effective range of ~3.6–10.0 (with VELOCITY_MIN=2.0, VELOCITY_MAX=10.0), and wants the code kept as-is with comments updated to document this behavior. Avoid suggesting changes to span the full 2.0–10.0 range in future reviews.

Learnt from: DedeHai Repo: wled/WLED PR: 4939 File: wled00/FX_fcn.cpp:1176-1187 Timestamp: 2025-09-16T18:08:42.848Z Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.

Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-11-14T13:37:11.994Z Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.

Learnt from: willmmiles Repo: wled/WLED PR: 4859 File: usermods/udp_name_sync/udp_name_sync.cpp:62-70 Timestamp: 2025-08-21T00:00:17.196Z Learning: In WLED codebase, UDP packet processing code must never rely on null termination being present on the wire and must always validate packet size first. The codebase already has some vulnerabilities where malformed data can crash the software, so avoiding introduction of new ones is a priority.

Learnt from: DedeHai Repo: wled/WLED PR: 4798 File: wled00/FX.cpp:7531-7533 Timestamp: 2025-08-26T11:51:21.817Z Learning: In WLED PR `#4798`, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.

Learnt from: BobLoeffler68 Repo: wled/WLED PR: 4891 File: wled00/FX.cpp:3333-3349 Timestamp: 2025-08-31T03:38:14.114Z Learning: WLED PacMan effect (wled00/FX.cpp): Keep pacmancharacters_t position fields as signed int (not int16_t). Maintainer preference (blazoncek) prioritizes avoiding potential overhead/regressions over minor RAM savings. Avoid type shrinking here unless memory pressure is demonstrated.

Learnt from: blazoncek Repo: wled/WLED PR: 5140 File: wled00/data/settings_time.htm:66-76 Timestamp: 2025-12-01T07:01:16.949Z Learning: In WLED PR `#5134`, the fix for macros being initialized with the enable bit set only handles new configurations, not existing ones. If there is a bug in timer/macro handling code (e.g., in settings_time.htm), it must be fixed to work correctly for existing configurations as well.

Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-12-28T14:06:48.772Z Learning: In WLED post-commit ee9ac947, the rendering pipeline uses per-segment buffers and per-pixel bus updates. Unmapped (0xFFFF) mapping entries are now skipped in WS2812FX::show() (no “clear to black”), which can leave physical gap LEDs with stale/random colors unless they are explicitly cleared. This is a behavior change from pre-0.16 where a full physical buffer was effectively refreshed each frame.

@coderabbitai line 123 uses the same condition - is that line still correct or does it also need to use (Channel >= chanSize) ?

@softhack007, line 123 (read()) is correct as-is with Channel > chanSize. The reason is that chanSize is assigned differently in each init function:

initRead(): chanSize = chanQuant (no +1)

initWrite(): chanSize = chanQuant + 1 (adds 1 for the start byte)

So for read() with max chanQuant = 512:

chanSize = 512

The check Channel > chanSize rejects anything above 512 ✓

Max valid access is dmxData[Channel - 1] = dmxData[511], well within the 0–512 index range ✓

For write() with max chanQuant = 512:

chanSize = 513

The check Channel > chanSize (i.e., > 513) allows Channel = 513

That would access dmxData[513] which is out of bounds ✗

So the off-by-one is isolated to write() only, and the fix Channel >= chanSize is needed there but not in read(). The two functions use chanSize with different semantics, which is admittedly a bit confusing but works correctly for read().

🧠 Learnings used

Learnt from: mval-sg Repo: wled/WLED PR: 4876 File: wled00/xml.cpp:0-0 Timestamp: 2025-08-28T08:09:20.630Z Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

Learnt from: mval-sg Repo: wled/WLED PR: 4876 File: wled00/wled_eeprom.cpp:0-0 Timestamp: 2025-09-01T10:26:17.959Z Learning: In WLED PR `#4876`, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.

Learnt from: DedeHai Repo: wled/WLED PR: 4926 File: wled00/FX.cpp:4727-4730 Timestamp: 2025-11-16T19:40:46.260Z Learning: WLED AuroraWave (wled00/FX.cpp): wave_start and wave_end intentionally use int16_t; segments longer than 32k LEDs are not supported (bounded by MAX_LEDS), so widening to 32-bit is unnecessary.

Learnt from: DedeHai Repo: wled/WLED PR: 4997 File: wled00/e131.cpp:33-44 Timestamp: 2025-10-10T18:34:06.550Z Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

Learnt from: softhack007 Repo: wled/WLED PR: 5442 File: wled00/bus_manager.cpp:462-468 Timestamp: 2026-03-23T23:33:45.480Z Learning: In WLED's TYPE_ANALOG_2CH_HBRIDGE (wled00/bus_manager.cpp), the dead zone at the CCT midpoint (level=127 and level=128 both producing _data[0]=0, _data[1]=0) is intentional by design. The map() blending is directional: WW channel (_data[0]) is brightest at level=0 and fades to 0 at level=127; CW channel (_data[1]) starts at 0 at level=128 and is brightest at level=255. The zero-output at the midpoint is the H-bridge polarity transition boundary, ensuring no overlap between the two polarity directions. Do not flag this dead zone as a bug in future reviews.

Learnt from: Mdbelen Repo: wled/WLED PR: 5522 File: wled00/dmx_output.cpp:5-9 Timestamp: 2026-04-21T23:32:50.241Z Learning: In WLED's `dmx_output.cpp` (ESP8266 path), `uart_tx_fifo_available()` is declared `inline __attribute__((always_inline))` in the ESP8266 Arduino core's `uart.cpp` and is NOT exported through any header. The workaround used is `#include "uart.cpp"` directly, which works because the function is always_inline (no ODR violation for that symbol). A cleaner alternative is to reproduce the one-liner body inline using the `USS()` and `USTXC` macros from `esp8266_peri.h`. Do not flag `#include "uart.cpp"` as an unconditional build failure for this file — it is a known limitation of the ESP8266 core's API surface.

Learnt from: BobLoeffler68 Repo: wled/WLED PR: 5109 File: wled00/FX.cpp:3174-3343 Timestamp: 2025-11-27T06:33:11.436Z Learning: WLED Ants effect (wled00/FX.cpp): The author prefers the current velocity initialization using hw_random16(1000, 5000)/5000.0f, resulting in an effective range of ~3.6–10.0 (with VELOCITY_MIN=2.0, VELOCITY_MAX=10.0), and wants the code kept as-is with comments updated to document this behavior. Avoid suggesting changes to span the full 2.0–10.0 range in future reviews.

Learnt from: BobLoeffler68 Repo: wled/WLED PR: 5440 File: usermods/user_fx/user_fx.cpp:1304-1313 Timestamp: 2026-03-25T07:03:35.475Z Learning: In WLED `mode_dissolveplus` (usermods/user_fx/user_fx.cpp), using `hw_random16(SEGLEN)` to select the survivor pixel index is correct and safe for this 1D-only effect. The 0xFFFF unmapped-entry concern from the physical bus mapping does not apply to 1D segments because virtual indices 0..SEGLEN-1 always map to valid physical LEDs without gaps. Do not flag this as a bug in future reviews of 1D effects.

Learnt from: softhack007 Repo: wled/WLED PR: 5457 File: usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h:0-0 Timestamp: 2026-03-31T17:31:01.023Z Learning: In WLED PR `#5457` (zigbee_rgb_light usermod): The WLED_MAX_DIGITAL_CHANNELS=0 build flag used in the esp32c6_zigbee environment is a temporary workaround for rmt_tx_wait_all_done() timeout spam when the Zigbee/802.15.4 stack is active. The root cause is under investigation and is likely related to Zigbee light-sleep (CONFIG_PM_ENABLE) disrupting RMT's internal time base, or ISR latency due to cache-disable during flash ops — NOT the 802.15.4 radio "sharing" the RMT peripheral (they are separate hardware). Because a proper fix (rmt_enable()/rmt_disable() PM-lock wrapping, allow_pd=0, CONFIG_RMT_TX_ISR_CACHE_SAFE) may eliminate the need to disable digital channels entirely, do NOT add a compile-time `#error` guard requiring WLED_MAX_DIGITAL_CHANNELS=0; doing so would prematurely bake in a constraint that may be lifted once the investigation concludes.

Learnt from: DedeHai Repo: wled/WLED PR: 5464 File: wled00/FX_fcn.cpp:1699-1701 Timestamp: 2026-04-09T07:26:09.816Z Learning: In WLED’s WLED code, if a pixel/buffer allocation uses `BFRALLOC_NOBYTEACCESS` (and especially on classic ESP32 where byte-level access to IRAM-resident buffers is unsafe), avoid using byte-wise operations like `memset`/`memcpy` on that buffer. Specifically, do not combine `BFRALLOC_CLEAR | BFRALLOC_NOBYTEACCESS` and do not perform `memcpy`/`memset` over `Segment::pixels` (e.g., in `setGeometry()`/`finalizeInit()` or copy ctor/assignment). Instead, use element-wise 32-bit access (loop over `uint32_t*` and assign/copy per element) to ensure 32-bit access only.

Learnt from: DedeHai Repo: wled/WLED PR: 5434 File: wled00/colors.cpp:79-83 Timestamp: 2026-03-21T11:43:36.767Z Learning: In WLED's `color_fade()` (wled00/colors.cpp), the `video=true` path computes `maxc = (maxc>>2) + 1` and only preserves a channel if its value strictly exceeds that threshold (`r > maxc`, etc.). This means very dark non-zero channels (e.g., r==1 or r==2) can be dropped to zero in video mode. This is intentional: it prevents flickering in corner regions of gradients and is an accepted design compromise. Do not flag this as a bug in future reviews.

Learnt from: willmmiles Repo: wled/WLED PR: 5462 File: wled00/json.cpp:1189-1198 Timestamp: 2026-03-30T15:32:08.847Z Learning: In WLED's `respondModeData()` (wled00/json.cpp), the 256-character `lineBuffer` limit for effect descriptor strings (getModeData) is an intentional constraint that matches the same 256-char limit used ~6 other places in the codebase. It is not new to this PR and should not be flagged as a regression. Lifting it requires a future refactor (better type system or dynamic buffer).

Learnt from: softhack007 Repo: wled/WLED PR: 5443 File: wled00/FX_fcn.cpp:1277-1277 Timestamp: 2026-03-24T12:10:32.630Z Learning: In WLED's `WS2812FX::service()` (wled00/FX_fcn.cpp), the old condition `|| (doShow && seg.mode == FX_MODE_STATIC)` was an **inclusion** guard — it caused FX_MODE_STATIC to render only when another segment had already set doShow=true. It did NOT skip or protect FX_MODE_STATIC from rendering. The PR `#5443` simplification removes this condition, meaning FX_MODE_STATIC now renders on every `timeToShow` tick uniformly. This is intentional and not a regression. Do not flag FX_MODE_STATIC special-casing as missing in future reviews of this function.

Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/cfg.cpp:673-673 Timestamp: 2026-03-28T00:51:30.926Z Learning: In WLED PR `#5048`, the NTP-related crash on ESP32-C5 (pioarduino IDF 5.5.x with CONFIG_LWIP_CHECK_THREAD_SAFETY=y) is definitively NOT caused by ntpUdp.begin(). The crash dump shows the real call chain: WLED::loop() → handleTime() → handleNetworkTime() (ntp.cpp:212) → AsyncDNS::query() (asyncDNS.h:45) → dns_gethostbyname_addrtype() → dns_alloc_pcb() → dns_alloc_random_port() → udp_new_ip_type() ← ASSERT. The fix must be in AsyncDNS::query() (asyncDNS.h:45): the call to dns_gethostbyname_addrtype() must be dispatched to the TCPIP thread via tcpip_callback_with_block() on IDF V5+. The ntpUdp.begin() call sites (wled.cpp:926 and set.cpp:562) are NOT the crash location for this particular bug.

Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/set.cpp:551-555 Timestamp: 2026-03-27T21:00:25.902Z Learning: In WLED PR `#5048` (wled00/set.cpp lines 551-555), the CONFIG_IDF_TARGET_ESP32C5 block that unconditionally forces ntpEnabled = false is an intentional **temporary hotfix** by softhack007 for a known ESP32-C5 crash: `assert failed: udp_new_ip_type udp.c:1278 (Required to lock TCPIP core functionality!)`. Do not flag this as a permanent design issue; the TODO comment in the code already notes it should be resolved properly once the underlying IDF/TCPIP bug on C5 is fixed. A future permanent solution should use a target capability flag rather than overwriting the user's setting.

Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2026-04-13T20:46:14.014Z Learning: In WLED (wled00/wled.cpp), on ESP32 with arduino-esp32 v2.0.x (IDF V4 branch), calling `pinMode(hardwareRX, INPUT_PULLDOWN)` has an unexpected side effect: it routes the RX pin through the GPIO matrix instead of keeping it on UART0's IOMUX path, effectively detaching the pin from the UART unit and causing serial receive to stop working (issue `#5501`). The correct way to enable a pull-down on the hardware RX pin without disrupting the UART mapping is to call `gpio_pulldown_en((gpio_num_t)hardwareRX)` directly from the ESP-IDF GPIO driver (`driver/gpio.h`). This is the fix applied in PR `#5503`. Do NOT use `pinMode()` to set pull resistors on UART RX/TX pins on ESP32.

Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/cfg.cpp:673-673 Timestamp: 2026-03-27T21:17:45.980Z Learning: When using lwIP “raw” APIs in WLED on ESP32 (Arduino-ESP32 / IDF 5.5+), don’t rely on LOCK_TCPIP_CORE()/UNLOCK_TCPIP_CORE() unless CONFIG_LWIP_TCPIP_CORE_LOCKING=y is guaranteed. CONFIG_LWIP_CHECK_THREAD_SAFETY=y can trigger the assertion “Required to lock TCPIP core functionality!” when raw lwIP calls occur off the TCPIP thread. If the locking mode isn’t enabled (or can’t be changed via sdkconfig), schedule lwIP work (e.g., ntpUdp.begin() and similar raw lwIP calls) via tcpip_callback() so it runs on the TCPIP thread; this should work regardless of the locking-mode setting. Review any similar raw lwIP usage for correct thread/context handling.

Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/cfg.cpp:673-673 Timestamp: 2026-03-27T21:17:45.980Z Learning: When calling raw lwIP APIs (e.g., around `ntpUdp.begin()` or any `lwIP`/`tcpip`-layer call) in this codebase on ESP32 Arduino-ESP32 platforms where core locking/checking is enabled, wrap the lwIP call with `LOCK_TCPIP_CORE()` / `UNLOCK_TCPIP_CORE()` from `lwip/tcpip.h`. This prevents thread-safety/core-violation crashes without requiring `sdkconfig` changes.

Learnt from: softhack007 Repo: wled/WLED PR: 5355 File: wled00/util.cpp:635-638 Timestamp: 2026-02-07T16:06:08.677Z Learning: PSRAM-related compilation guards should enable PSRAM code only for ESP32 variants that actually include PSRAM: ESP32-C61, ESP32-C5, and ESP32-P4. Exclude ESP32-C3, ESP32-C6, and ESP8266 from these guards. Apply this rule across the codebase (not just wled00/util.cpp) by reviewing and updating PSRAM guards/macros in all relevant files (C/C++ headers and sources).

Learnt from: softhack007 Repo: wled/WLED PR: 4893 File: wled00/set.cpp:95-95 Timestamp: 2026-03-14T20:56:46.543Z Learning: Guideline: Ensure WiFi hostname is set after WiFi.mode() but before WiFi.begin() to avoid default esp-XXXXXX hostname being used in DHCP. This ordering only takes effect after the STA interface exists (so avoid placing hostname setting before initConnection). In WLED, place the hostname configuration inside initConnection() (after WiFi.disconnect(true) and before WiFi.begin()) rather than in earlier boot code like deserializeConfig(). This rule should be applied in code reviews for WLED’s network initialization paths in wled00/*.cpp, and note that on ESP8266 the ordering is less strict but still desirable for consistency.

Learnt from: softhack007 Repo: wled/WLED PR: 4838 File: lib/NeoESP32RmtHI/src/NeoEsp32RmtHIMethod.cpp:30-35 Timestamp: 2026-03-27T12:33:48.499Z Learning: In C/C++ preprocessor conditionals (`#if`, `#elif`) GCC/Clang treat `&&` as short-circuit evaluated during preprocessing. This means guards like `#if defined(ARDUINO_ARCH_ESP32) && ESP_IDF_VERSION < ESP_IDF_VERSION_VAL(5, 0, 0)` are safe even if the macro/function-like macro on the RHS (e.g., `ESP_IDF_VERSION_VAL`) is not defined on some targets, because the RHS will not be expanded when the LHS is false (e.g., `defined(...)` evaluates to 0). During code review, avoid flagging such cases as “undefined function-like macro invocation” if they are protected by short-circuiting `defined(...) && ...`/`||` logic; some tools like cppcheck may not model this and can produce false positives. Also, don’t suggest refactoring that moves ESP32-specific includes/headers (e.g., `esp_idf_version.h`) outside of these guarded preprocessor blocks, since that will break targets (e.g., ESP8266) where the headers don’t exist.

Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/wled.cpp:698-700 Timestamp: 2026-03-28T01:37:15.541Z Learning: In this WLED codebase, when using `DEBUG_PRINTLN(F("..."))`, an explicit trailing `\n` inside the `F("...")` string (e.g., `DEBUG_PRINTLN(F("Warning!\n"))`) may be intentional to create a blank line in debug output as a visual separator. During code review, do not automatically flag these as “double newline” or recommend removing the `\n`—first verify with the author/context that the extra newline is deliberate.

Learnt from: willmmiles Repo: wled/WLED PR: 5462 File: wled00/json.cpp:1189-1198 Timestamp: 2026-03-30T15:32:02.808Z Learning: When working with WLED strings stored in PROGMEM on ESP8266/ESP32, assume you can’t use `strchr_P` for character scanning. If you need to scan a PROGMEM string for a character (e.g., searching for '@' within effect data), review changes to ensure they perform an explicit RAM copy first (e.g., via `strncpy_P` into a buffer) and then scan in RAM. Avoid proposing incremental/streaming PROGMEM character-by-character scans without a RAM buffer on these targets, since it’s impractical with the available APIs.

Learnt from: softhack007 Repo: wled/WLED PR: 5480 File: docs/cpp.instructions.md:267-491 Timestamp: 2026-04-08T15:03:02.041Z Learning: In this codebase, the upstream FastLED library has been replaced by the custom `fastled_slim` fork. Do not call the legacy FastLED trig alias names `sin8()`, `cos8()`, `sin16()`, or `cos16()` (they have no backward-compat shims and will fail compilation). Use only the fork’s supported names: `sin8_t()`, `cos8_t()`, `sin16_t()`, `cos16_t()` (declared in `fastled_slim.h`, implemented in `wled_math.cpp`) for the fixed-point variants, and use `sin_approx()` / `cos_approx()` for float approximations.

Learnt from: DedeHai Repo: wled/WLED PR: 5464 File: wled00/FX_fcn.cpp:1699-1701 Timestamp: 2026-04-09T09:14:29.218Z Learning: In WLED, when reviewing ESP32 code that uses pixel buffers allocated with `BFRALLOC_NOBYTEACCESS` (e.g., `WS2812FX::_pixels` and `Segment::pixels`), treat `memset`/`memcpy` on those buffers as an intentionally low-risk, accepted pattern. These buffers are designed to be IRAM-safe for 32-bit-only access, and the Xtensa newlib assembly implementations perform 32-bit word stores for word-aligned, word-multiple-sized buffers (so the IRAM constraint is satisfied in practice). Do not flag `memset`/`memcpy` on `BFRALLOC_NOBYTEACCESS` pixel buffers as a critical bug; if any concern arises, downgrade severity to low and focus on potential future regressions rather than an immediate correctness violation.

-Original file line number
+Diff line change
@@ Expand Up / @@ -23,7 +23,6 @@ Distributed as-is; no warranty is given. @@
     #include <HardwareSerial.h>
     #define dmxMaxChannel  512
-    #define defaultMax 32
     #define DMXSPEED       250000
     #define DMXFORMAT      SERIAL_8N2
@@ Expand Down Expand Up / @@ -90,7 +89,7 @@ void SparkFunDMX::initRead(int chanQuant) { @@
       _READWRITE = _READ;
       if (chanQuant > dmxMaxChannel || chanQuant <= 0)
       {
-        chanQuant = defaultMax;
+        chanQuant = dmxMaxChannel;
       }
       chanSize = chanQuant;
       if (enablePin >= 0) {
@@ Expand All / @@ -106,7 +105,7 @@ void SparkFunDMX::initWrite (int chanQuant) { @@
       _READWRITE = _WRITE;
       if (chanQuant > dmxMaxChannel || chanQuant <= 0) {
-        chanQuant = defaultMax;
+        chanQuant = dmxMaxChannel;
       }
       chanSize = chanQuant + 1; //Add 1 for start code
@@ Expand All / @@ -121,17 +120,15 @@ void SparkFunDMX::initWrite (int chanQuant) { @@
     #if !defined(DMX_SEND_ONLY)
     // Function to read DMX data
     uint8_t SparkFunDMX::read(int Channel) {
-      if (Channel > chanSize) Channel = chanSize;
+      if ((Channel < 1) || (Channel > chanSize)) return 0;
       return(dmxData[Channel - 1]); //subtract one to account for start byte
     }
     #endif
     // Function to send DMX data
     void SparkFunDMX::write(int Channel, uint8_t value) {
-      if (Channel < 0) Channel = 0;
-      if (Channel > chanSize) chanSize = Channel;
-      dmxData[0] = 0;
-      dmxData[Channel] = value; //add one to account for start byte
+      if ((Channel < 1) || (Channel > chanSize)) return;
+      dmxData[Channel] = value; //start byte at dmxData[0]
     }
@@ Expand Down @@

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fixed bug of ESP32 crashing when using DMX out #5316

Diff view

Diff view

There are no files selected for viewing

coderabbitai Bot Apr 28, 2026

Uh oh!

coderabbitai Bot Jan 24, 2026 •

edited

Loading

Uh oh!

softhack007 Jan 25, 2026

Uh oh!

coderabbitai Bot Jan 25, 2026

Uh oh!

softhack007 Apr 28, 2026

Uh oh!

coderabbitai Bot Apr 28, 2026

Uh oh!

Uh oh!

Uh oh!

Fixed bug of ESP32 crashing when using DMX out #5316

Are you sure you want to change the base?

Fixed bug of ESP32 crashing when using DMX out #5316

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

coderabbitai Bot Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

softhack007 Jan 25, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Jan 25, 2026

Choose a reason for hiding this comment

Uh oh!

softhack007 Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

coderabbitai Bot Jan 24, 2026 •

edited

Loading