Larry Bank emailed me after reading the retained-state post. He's spent years debugging SPI and parallel e-paper panels, and he pushed back on three specific claims. He was right about most of it. Here's the follow-up.
Since writing that post I replaced the XIAO ESP32-C3 I'd been testing on. The old one turned out to be degraded hardware. On a known-good board, every panel that "locked up" now runs clean. Same driver, same code. Zero of the failures I wrote about.
The lockup wasn't a controller flaw #
I claimed a hardware reset couldn't clear the latched-busy state, and only removing power did. That framing is wrong. Underneath the bad board sat three real driver bugs:
- No
POWER_ONbefore each refresh, so the charge pump dropped and the nextDISPLAY_REFRESHwas silently ignored. - A BUSY poll that ran before the controller had actually asserted the line, a genuine race condition.
- A reset pulse at 2 ms, too short to latch reliably. Some vendor drivers use 30 ms for the same controller.
Fix those three and the "lockup" is gone. My driver hadn't told the controller what it needed to know before asking it to work. That's Larry's exact objection, and it's correct.
Shifted, clipped content: same root cause #
I photographed a panel showing content shifted and clipped and called it a RAM-window bug. It wasn't. It was the same BUSY race above: I was writing a new frame into controller RAM while the previous refresh was still running in the background, because I wasn't waiting for the real BUSY edge. The panel rendered exactly what was in its RAM at the moment I photographed it, not a stride miscalculation.
Colour panels: what I can actually claim #
The original post said colour panels are slow "and that's physics": the heavier colour pigment needs the full waveform to migrate. Larry's rebuttal: the particles move at comparable speed to black/white ink given the right voltage rails. Slow colour updates are a choice vendors make in their waveform tables, not a hard limit of the medium.
I have no basis to argue the physics either way, so I'm not going to. What I can stand behind is narrower: for the controllers I've implemented against vendor reference drivers (SSD1681, JD79661, UC8253), the shipped waveform tables and command sets don't expose a fast or partial path for the colour plane. Select "partial" on any of them and you still get a full slow update, just with the colour discarded. That's a claim about what these specific ICs and reference firmwares implement.
What still holds #
The debugging lesson stands. I was reasoning from a run contaminated by the one before it, and from a diagnostic that reported numbers it never measured. Pull the power, watch the panel, distrust the log. That part of the post I'd write again unchanged.
The lockup and the colour-speed claims said more than I knew. Thanks to Larry for reading closely enough to catch it.