With no DataBus config block, the firmware falls back to Wire.begin()
on the chip's default I2C pins. On ESP32-S3 those are GPIO 8/9 — which
on the M5Stack PaperS3 are EPD data lines. Result: every render corrupts
into stripes/column artifacts, with no hint that I2C is the cause. This
was the root cause of our hardest bring-up defect.
Proposal: skip the Wire fallback (or WARN loudly) when no DataBus is
configured, or at least when the default pins overlap pins the display
path claims. A config-time WARN ("no DataBus configured — I2C falls back
to GPIO x/y") would already save days of diagnosis on parallel-panel
boards.
With no DataBus config block, the firmware falls back to
Wire.begin()on the chip's default I2C pins. On ESP32-S3 those are GPIO 8/9 — which
on the M5Stack PaperS3 are EPD data lines. Result: every render corrupts
into stripes/column artifacts, with no hint that I2C is the cause. This
was the root cause of our hardest bring-up defect.
Proposal: skip the Wire fallback (or WARN loudly) when no DataBus is
configured, or at least when the default pins overlap pins the display
path claims. A config-time WARN ("no DataBus configured — I2C falls back
to GPIO x/y") would already save days of diagnosis on parallel-panel
boards.