esp32-d0-pico2 fixes #108
esp32-d0-pico2 fixes #108
Conversation
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
Documentation Update docs/gettingstarted/installer.md |
Clarified ESP32 device LED specifications: updated from generic "up to 4096 LEDs" to specify "up to 1024 LEDs at 30 FPS on single output" or "4096 LEDs over Art-Net/network" for more accurate capability description. |
Configuration Annotation firmware/esp32-d0.ini |
Added comment line in env:esp32-d0-pico2 section noting "Core dump flash config is corrupted!" — non-functional annotation without altering actual configuration. |
Estimated code review effort
🎯 1 (Trivial) | ⏱️ ~2 minutes
Poem
🐰 A doc so clear, a note so brief,
LED counts bring us relief,
Single or networked, we now know,
How far these little signals go! ✨
🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 inconclusive)
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Title check | ❓ Inconclusive | The title 'esp32-d0-pico2 fixes' is vague and generic, referring only to the device/config file without clearly indicating what was actually fixed or changed. | Consider a more specific title that describes the actual changes, such as 'Update ESP32-D0-Pico2 LED capabilities documentation and add core dump note' or 'Document expanded LED support for ESP32-D0-Pico2'. |
✅ Passed checks (2 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
✏️ Tip: You can configure your own custom pre-merge checks in the settings.
🧹 Recent nitpick comments
firmware/esp32-d0.ini (1)
122-123: Clarify the core dump flash configuration issue.The comment "Core dump flash config is corrupted!" lacks context about severity, impact, and whether this requires action. Consider:
- Is this a known issue that affects device functionality or debugging capabilities?
- Should this be tracked as a TODO or linked to an issue?
- Does this impact end users or only developers debugging crashes?
- Are there any workarounds or plans to fix this?
If this is a blocking issue that needs resolution, would you like me to help investigate the core dump configuration settings for the esp32-d0-pico2 board or open a tracking issue?
📜 Recent review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/gettingstarted/installer.mdfirmware/esp32-d0.ini
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2026-01-06T13:45:03.067Z
Learning: For MoonLight on ESP32 at extreme loads (e.g., 49K channels @ 100 fps): Task watchdog can fire when AppDrivers/AppEffects process many nodes without yielding. Even with vTaskDelay(1) at loop end, the node iteration for-loops (PhysicalLayer::loopDrivers line 108-111, PhysicalLayer::loop line 73-75) can take >5 seconds without yielding, starving IDLE task (priority 0). Solution: add taskYIELD() or vTaskDelay(1) inside the node/layer iteration loops to give IDLE task chances to run and reset watchdog. Lowering task priority won't help since IDLE is already at 0 (lowest).
Learnt from: CR
Repo: MoonModules/MoonLight PR: 0
File: misc/parking/GEMINI.md:0-0
Timestamp: 2025-11-29T16:17:30.619Z
Learning: Applies to misc/parking/src/**/*.{h,cpp} : Modify C++ backend code in the `src/` and `lib/` directories for ESP32 development
Learnt from: ewowi
Repo: MoonModules/MoonLight PR: 0
File: :0-0
Timestamp: 2025-12-25T13:31:32.367Z
Learning: For ESP32 LED drivers using DMA, I2S, LCD, or PARLIO: always pin driver tasks to Core 1 (APP_CPU), not Core 0. WiFi/BT runs at priority ~23 on Core 0 and would constantly preempt lower-priority driver tasks, breaking LED timing requirements. ESP-IDF explicitly recommends display/DMA processing on Core 1 to avoid WiFi interference.
📚 Learning: 2025-11-29T16:17:30.619Z
Learnt from: CR
Repo: MoonModules/MoonLight PR: 0
File: misc/parking/GEMINI.md:0-0
Timestamp: 2025-11-29T16:17:30.619Z
Learning: Applies to misc/parking/**/factory_settings.ini : Configure default or factory-set ESP32 parameters in `factory_settings.ini`
Applied to files:
firmware/esp32-d0.ini
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (1)
docs/gettingstarted/installer.md (1)
16-16: Documentation clarification improves user expectations.The updated description better distinguishes between single output capabilities (1024 LEDs @ 30FPS) and network-based capabilities (4096 LEDs via Art-Net), helping users understand hardware limitations and plan their LED setups accordingly.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
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 @coderabbitai help to get the list of available commands and usage tips.
|
@coderabbitai, I have this new esp32 MCU definition: [env:esp32-d0-pico2] And used it to flash to a ESP32-PICO-Mini-02 : ESP32 based, Dual-Core 240Mhz microcontroller, 8MB Flash, 2MB PSRAM, more info here: https://documentation.espressif.com/esp32-pico-mini-02_datasheet_en.pdf In esp32-d0.ini, imported in platformio.ini I used board = esp32-pico-devkitm-2 which I believe takes the definition from https://github.com/platformio/platform-espressif32/blob/master/boards/esp32-pico-devkitm-2.json (can you check it this is how it works using board =). When flashing I got this: [13:50:02]ELF file SHA256: 7dc328089 Can you investigate what is going on? And propose changes to my [env:esp32-d0-pico2] if needed, to make this definition work for ESP32-PICO-Mini-02 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 21 🌐 Web query: 💡 Result: I found the official PlatformIO board page and the board manifest on GitHub. Do you want me to paste the full esp32-pico-devkitm-2.json here, or just show how to reference/use it in platformio.ini? [PlatformIO docs] [GitHub manifest]. Sources: Citations: 🏁 Script executed: Length of output: 6410 🌐 Web query: 💡 Result: Likely causes
Quick fixes (try in order)
What to check if problem persists
References
If you want, tell me: board model (ESP32, S2, S3, C3, module name), current IDE/PlatformIO settings, and the exact serial log and I’ll give exact commands/setting values. 🏁 Script executed: Length of output: 1172 🌐 Web query: 💡 Result: Short answer — for an ESP32‑PICO‑MINI‑02 (8 MB flash / 2 MB PSRAM) in PlatformIO (Arduino framework) set PSRAM as SPI (QIO) and enable PSRAM via build flags. Example platformio.ini entries: References: ESP32‑PICO‑MINI‑02 datasheet (shows 2 MB PSRAM). [1] PlatformIO docs on enabling external RAM / Arduino flags. [2] Example PlatformIO configs showing memory_type / psram_type = qio for ESP32 boards. [3] Sources:
Root Causes
Fixed ConfigurationHere's the corrected [env:esp32-d0-pico2]
board = esp32-pico-devkitm-2 ; https://github.com/platformio/platform-espressif32/blob/master/boards/esp32-pico-devkitm-2.json
board_build.partitions = boards/ESP32_8MB.csv ; Fixed: was default_8MB.csv (doesn't exist)
board_build.arduino.memory_type = qio_qspi ; Added: PSRAM memory type
board_build.flash_mode = qio ; Added: Flash mode for PSRAM
build_flags = ${esp32-d0-base.build_flags}
-D HTTPD_STACK_SIZE=6144
-DBOARD_HAS_PSRAM ; Added: Enable PSRAM
-mfix-esp32-psram-cache-issue ; Added: Fix ESP32 PSRAM cache bug
lib_deps = ${esp32-d0-base.lib_deps}Key Changes Explained
Next StepsBefore reflashing with the new configuration, erase the entire flash to clear the corrupted core dump partition: # Using PlatformIO
pio run -t erase
# Or using esptool directly
esptool.py --port <YOUR_PORT> erase_flashThen upload with the corrected configuration. About Board DefinitionYes, you're correct about how Let me know if this resolves the issues! 🧠 Learnings used |
|
@coderabbitai, regarding
When I use board_build.partitions = boards/ESP32_8MB.csv I got: Error: The program size (2349899 bytes) is greater than maximum allowed (2097152 bytes) why is that? as it exists in the boards folder... (check it's contents please) but when I used default_8MB.csv it works fine: RAM: [== ] 18.8% (used 61728 bytes from 327680 bytes) You say it is not defined in boards but isn't this some globally available definition? Furthermore regarding
In https://github.com/platformio/platform-espressif32/blob/master/boards/esp32-pico-devkitm-2.json I can find "extra_flags": [ "flash_mode": "qio", there is only not arduino.memory_type = qio_qspi so we don't need to specify -DBOARD_HAS_PSRAM and oard_build.flash_mode = qio isn't it? and do we need -mfix-esp32-psram-cache-issue for this board? So concluding: the only real change you propose is adding arduino.memory_type = qio_qspi and maybe -mfix-esp32-psram-cache-issue. Is that indeed what was missing bottom line? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 1736 🏁 Script executed: Length of output: 6203
Partition File ClarificationYou're right: The key difference:
So stick with Board JSON FlagsYou're also right about the redundant flags! The board JSON at
So you don't need to re-specify these in your platformio.ini. What About -mfix-esp32-psram-cache-issue?This flag is still recommended because:
Looking at your Bottom Line: The Actual FixYes, you're exactly right! The minimal changes needed are: [env:esp32-d0-pico2]
board = esp32-pico-devkitm-2
board_build.partitions = default_8MB.csv ; Framework default with 3.3MB app partitions
board_build.arduino.memory_type = qio_qspi ; ← THIS was missing (enables PSRAM)
build_flags = ${esp32-d0-base.build_flags}
-D HTTPD_STACK_SIZE=6144
-mfix-esp32-psram-cache-issue ; ← Safety for ESP32 Rev1 cache bug (optional but recommended)
lib_deps = ${esp32-d0-base.lib_deps}Root Cause of Original CrashThe LoadStoreError happened because:
The core dump error was just a side effect of the crash happening early in boot before that partition was initialized. TL;DR: You nailed it — ✏️ Learnings added
🧠 Learnings used |
|
@coderabbitai, still same crash. I read somewhere else ( MoonModules/WLED-MM#322 ), maybe related?: _Switching to flash_mode = dio: The standard QIO mode was too unstable when the HUB75 driver was active, leading to flash write failures. So should I change qio to dio? Please also explain what it does, maybe @intermittech had the right setting for this after all 🙂 |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 17977
DIO vs QIO ExplainedQIO (Quad I/O): Uses 4 data lines for flash communication, up to 4× faster than standard. DIO (Dual I/O): Uses 2 data lines for flash communication. Performance order: QIO > QOUT > DIO > DOUT The key difference: In QIO mode, two additional GPIOs are used for SPI flash communications (SPIWP and SPIHD pins). If flash mode is set to DIO then these pins are available for other purposes. Pin Conflicts with HUB75 and Other DriversYour codebase does use HUB75 drivers (found When using high-bandwidth drivers (HUB75, parallel LED drivers), QIO mode can cause:
The WLED-MM reference you found is highly relevant — switching to DIO resolved HUB75 driver instability there. But Wait — PICO-D4 Caveat!However, I found a conflicting report: When flashing with QIO mode all is well, when flashing with DIO mode the sketch fails to talk the the built-in flash correctly on PICO-D4 boards. This suggests PICO boards may have unique flash wiring that actually requires QIO. Critical QuestionsBefore recommending DIO, I need to understand the current situation:
The fact that you're still getting the same crash suggests one of two things:
What to TryOption 1: Verify current config and check boot log [env:esp32-d0-pico2]
board = esp32-pico-devkitm-2
board_build.partitions = default_8MB.csv
board_build.arduino.memory_type = qio_qspi ; ← Make sure this is present
build_flags = ${esp32-d0-base.build_flags}
-D HTTPD_STACK_SIZE=6144
-mfix-esp32-psram-cache-issue
lib_deps = ${esp32-d0-base.lib_deps}Check the boot log — does it say Option 2: Try DIO flash mode (if Option 1 confirms PSRAM is initialized but still crashing) [env:esp32-d0-pico2]
board = esp32-pico-devkitm-2
board_build.partitions = default_8MB.csv
board_build.arduino.memory_type = dio_qspi ; ← Changed from qio_qspi
board_build.flash_mode = dio ; ← Override QIO
build_flags = ${esp32-d0-base.build_flags}
-D HTTPD_STACK_SIZE=6144
-mfix-esp32-psram-cache-issue
lib_deps = ${esp32-d0-base.lib_deps}Can you share: The current complete config you're using, and the full boot log (first ~50 lines) so we can see if PSRAM is actually being found? 🧠 Learnings used |
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.