Fix board misidentification when OPI-PSRAM is disabled

[ainyan03]

Overview

When a build lacks OPI-PSRAM, boards whose display requires it were misidentified as display-less models: the detection block had already identified the board, but skipping the panel setup let the autodetection fall through to board_unknown, and the caller then guessed a wrong model (e.g. M5StopWatch was reported as an AtomS3Lite).

Changes

• M5StopWatch: remove the OPI-PSRAM requirement entirely. Panel_CO5300 supports direct drawing — the optional PSRAM frame buffer (initPanelFb) may fail to allocate and is not required — so the guard (introduced alongside the EPD boards, which genuinely need the buffer) was unnecessary.
• EPD boards (PaperMono / PaperS3 / PaperDIY / PaperColor / ChainCaptain): these genuinely require PSRAM for the frame buffer, so the guard stays — but jump to init_clear after logging so the board identification is kept and only the display stays unavailable.

Verification (real hardware)

• M5StopWatch: without PSRAM — correct board, display works via direct drawing; with OPI-PSRAM — unchanged
• M5PaperColor / M5PaperMono: without PSRAM — correct board retained with the requirement logged, no crash; with OPI-PSRAM — normal detection and display initialization
• Builds green with and without OPI-PSRAM

[Copilot]

Pull request overview

Fixes ESP32S3 board autodetection so boards that require OPI-PSRAM for their display buffer remain correctly identified even when OPI-PSRAM is disabled, instead of falling through to board_unknown and being mis-guessed by the caller. It also removes an unnecessary OPI-PSRAM requirement for M5StopWatch, relying on direct drawing when the optional framebuffer allocation fails.

Changes:

• Removed the OPI-PSRAM compile-time guard for M5StopWatch panel setup (direct drawing remains usable without a PSRAM framebuffer).
• For EPD boards, kept the OPI-PSRAM requirement but added early exits (goto init_clear) so board identification is preserved even when display init is skipped.

Suppressed comments (3)

src/M5GFX.cpp:2107

• These PSRAM-missing early-exit branches jump to init_clear without creating a new panel/touch. Since init_clear unconditionally applies _panel_last (panel(_panel_last.get())), a subsequent autodetect() call could accidentally reattach a stale panel/touch from a previous init. Clear _panel_last (and _touch_last) before goto init_clear to guarantee the display is actually unavailable in this path.

            ESP_LOGE(LIBRARY_NAME, "M5ChainCaptain needs OPI-PSRAM enabled");
            goto init_clear; // keep the board identification; the display stays unavailable
#elif !defined (CONFIG_SPIRAM_MODE_OCT)
            ESP_LOGE(LIBRARY_NAME, "M5ChainCaptain needs OPI-PSRAM enabled");
            goto init_clear; // keep the board identification; the display stays unavailable

src/M5GFX.cpp:2192

• These PSRAM-missing early-exit branches jump to init_clear without creating a new panel/touch. Since init_clear unconditionally applies _panel_last (panel(_panel_last.get())), a subsequent autodetect() call could accidentally reattach a stale panel/touch from a previous init. Clear _panel_last (and _touch_last) before goto init_clear to guarantee the display is actually unavailable in this path.

              ESP_LOGE(LIBRARY_NAME, "M5PaperColor need OPI-PSRAM enabled");
              goto init_clear; // keep the board identification; the display stays unavailable
#elif !defined (CONFIG_SPIRAM_MODE_OCT)
              ESP_LOGE(LIBRARY_NAME, "M5PaperColor need OPI-PSRAM enabled");
              goto init_clear; // keep the board identification; the display stays unavailable

src/M5GFX.cpp:2320

• These PSRAM-missing early-exit branches jump to init_clear without creating a new panel/touch. Since init_clear unconditionally applies _panel_last (panel(_panel_last.get())), a subsequent autodetect() call could accidentally reattach a stale panel/touch from a previous init. Clear _panel_last (and _touch_last) before goto init_clear to guarantee the display is actually unavailable in this path.

            ESP_LOGE(LIBRARY_NAME, "%s need OPI-PSRAM enabled", board == board_t::board_M5PaperDIY ? "M5PaperDIY" : "M5PaperS3");
            goto init_clear; // keep the board identification; the display stays unavailable
#elif !defined (CONFIG_SPIRAM_MODE_OCT)
            ESP_LOGE(LIBRARY_NAME, "%s need OPI-PSRAM enabled", board == board_t::board_M5PaperDIY ? "M5PaperDIY" : "M5PaperS3");
            goto init_clear; // keep the board identification; the display stays unavailable

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (4)

src/M5GFX.cpp:2115

• The PSRAM guard for M5ChainCaptain repeats the same log/reset/goto in both the SPIRAM support and SPI mode checks. Consider merging these into a single #if !(...) || !defined(...) condition to avoid duplicated maintenance.

#if !(defined(CONFIG_ESP32S3_SPIRAM_SUPPORT))
            ESP_LOGE(LIBRARY_NAME, "M5ChainCaptain needs OPI-PSRAM enabled");
            _panel_last.reset();
            _touch_last.reset();
            goto init_clear; // keep the board identification; the display stays unavailable

src/M5GFX.cpp:2204

• The PSRAM guard for M5PaperColor contains two identical error-handling branches for the SPIRAM-support and OCT-mode checks. This can be collapsed into a single combined preprocessor condition to reduce duplication.

#if !(defined(CONFIG_ESP32S3_SPIRAM_SUPPORT))
              ESP_LOGE(LIBRARY_NAME, "M5PaperColor need OPI-PSRAM enabled");
              _panel_last.reset();
              _touch_last.reset();
              goto init_clear; // keep the board identification; the display stays unavailable

src/M5GFX.cpp:2336

• The PSRAM guard for M5PaperDIY/M5PaperS3 duplicates the same error-handling block across two preprocessor branches. Combining the checks into one #if reduces duplication and keeps the guard consistent with other boards.

#if !(defined(CONFIG_ESP32S3_SPIRAM_SUPPORT))
            ESP_LOGE(LIBRARY_NAME, "%s need OPI-PSRAM enabled", board == board_t::board_M5PaperDIY ? "M5PaperDIY" : "M5PaperS3");
            _panel_last.reset();
            _touch_last.reset();
            goto init_clear; // keep the board identification; the display stays unavailable

src/M5GFX.cpp:2005

• The PSRAM guard for PaperMono duplicates the same error/cleanup block in both the SPIRAM support and SPI mode checks. This duplication makes future edits error-prone; the two branches can be combined into a single preprocessor condition like the M5StopWatch warning block.

This issue also appears in the following locations of the same file:

• line 2111
• line 2200
• line 2332

#if !(defined(CONFIG_ESP32S3_SPIRAM_SUPPORT))
              ESP_LOGE(LIBRARY_NAME, "M5PaperMono need OPI-PSRAM enabled");
              _panel_last.reset();
              _touch_last.reset();
              goto init_clear; // keep the board identification; the display stays unavailable