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 |
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.