Hi, I’m driving the ePaper Driver Board for XIAO (V2) with the 2.13" monochrome SSD1680 panel directly from a Raspberry Pi Zero W over SPI. No XIAO is in the socket.
What works: the same board and panel with a XIAO ESP32-C3 in the socket, running ESPHome waveshare_epaper model 2.13inv3. The display refreshes fine.
Wiring from the Pi (per the EPAPER_IO_V20 schematic, soldered, ~15 cm):
RST→D0 (Pi pin 11), CS→D1 (pin 24, CE0), BUSY→D2 (pin 18), DC→D3 (pin 22), SCK→D8 (pin 23), MOSI→D10 (pin 19), 3V3→3V3 (pin 17), GND→GND. The 5V pad is not connected.
What happens: the controller seems to answer, but every full refresh finishes within 5–20 ms and no pixel moves. There is no flash at all. BUSY reads inconsistently: sometimes it looks floating, sometimes driven.
Already tried:
Waveshare V3 sequence: LUT via 0x32, 0x3F/0x03/0x04/0x2C, refresh 0x22=0xC7. Also the OTP refresh with 0xF7.
Writing both RAMs (0x24 and 0x26).
Seeed_GFX reset timing (10 ms low / 120 ms high).
SPI clock from 100 kHz to 4 MHz, mode 0.
3.26 V measured on CT1 (220 µF) with the Pi running.
Questions:
Does the V2 board need anything from the XIAO socket beyond 3V3, GND and the six signals? For example 5V on VDD_5V, the power switch position, or anything else.
Has anyone run this board from a Raspberry Pi or another host that isn’t a XIAO?
So reply and comment a coupe more times , you will be able to post a picture.
But < i see this with SeeedLLM;
"
The board-to-board pin mapping between the XIAO socket and the display is correct, but there is a clear physical wiring discrepancy on the Raspberry Pi header alongside a power rail trap:
1. The Pi Wiring Mix-up (Pin 11 vs. Pin 17)
Look closely at his Pi pin assignments:
He states: RST → D0 (Pi pin 11) and 3V3 → 3V3 (pin 17).
On the standard 40-pin Raspberry Pi header, Physical Pin 11 is GPIO 17.
Physical Pin 17 is actually 3V3 Power.
If his Pi code/driver is configured using BCM numbering (e.g., rst_pin = 17 or rst_pin = 11), he is either referencing the wrong BCM pin or has inadvertently crossed physical pin 11 with physical pin 17 (3.3V).
If RST is tied to a floating/wrong GPIO that never gets pulled high, the SSD1680 stays in reset or aborts initialization. If it is floating, the controller will read back random/zero responses, refresh will exit in 5–20 ms, and BUSY will appear floating or glitchy.
2. The Power Rail & Switch Trap
On the Seeed ePaper Driver Board for XIAO:
The onboard slide switch disconnects battery/power rails. On several revisions of Seeed’s driver boards, the 3.3V bus feeding the SSD1680 charge pump and booster circuitry is power-gated or expects the onboard switch to be in the “ON” position.
When powered purely through the header pad without a XIAO onboard, if the power switch is in the OFF position or the panel’s VDD/VDDIO rails are isolated, logic pins will show high via ESD diodes (giving the 3.26V reading on the bulk capacitor), but the internal DC-DC booster driving the gate/source lines will never fire.
Verification Checklist to Reply With:
Confirm Pi BCM vs. Physical Pinning:
Pi Pin 11 = BCM GPIO 17
Pi Pin 18 = BCM GPIO 24
Pi Pin 22 = BCM GPIO 25
Pi Pin 24 = BCM GPIO 8 (CE0)
Ensure the script defines BCM numbers rather than board physical pin numbers.
Slide Switch State: Flip the onboard slide switch to ON.
Reset Line State: Verify with a multimeter that RST idles at a stable 3.3V HIGH during and after boot. "
HTH
GL:-) PJ
Let us know how it shakes out. FIX the connection,
I double-checked both points against the board and the V2 schematic (EPAPER_IO_V20):
The driver uses BCM numbering (GPIO.setmode(GPIO.BCM)): RST = BCM17 on physical pin 11, BUSY = BCM24 on pin 18, DC = BCM25 on pin 22, CS = CE0/BCM8 on pin 24. 3V3 comes from physical pin 17, which is a 3V3 pin, so there’s no mix-up there.
On the V2 schematic the slide switch CN6 only sits between the battery connector and the ETA9740’s BAT pin. The 3V3 rail goes from the header straight through FB1 to CT1, the panel’s VCI/VDDIO and the booster, and nothing gates it. So the 3.26 V on CT1 is the real supply. But anyway, i have the switch in “ON” position.
I’m now running a diagnostic that times the BUSY pulse after a SW reset (0x12) at different SPI speeds. It checks whether commands reach the controller at all, and whether DC and RST gate them. I’ll post the results.
Ok, good info, definetly slow it down SPI wise see if it changes, the BUSY line often messes everything up Timing or polarity, Xiao is Active LOW of LED’s for example…
Thanks PJ! I already tried slowing SPI down: 20 kHz, 100 kHz, 1 MHz and 4 MHz, and also with slew-limited GPIO pads. No difference. BUSY is read as active-HIGH, the same as ESPHome, which works on this board.
New findings:
With the Pi connected, BUSY toggles as a ~50% duty square wave at roughly 150–200 Hz. This happens before any SPI traffic, and even while RST is held LOW.
With the FPC ribbon unplugged, the Pi’s BUSY input is perfectly quiet. So the panel side is producing the square wave.
With the XIAO back in the socket, the same board and panel refresh fine.
So something the Pi feeds into the board puts the SSD1680 into this state, either the 3V3 supply or one of the control lines. I’m now isolating which, and I’ll report back.
SO sounds like a grounding issue to me,
I know from using them for OctoPie
A Raspberry Pi Zero W’s onboard 3.3V rail (derived from its tiny onboard PAM2306 / RT8059 buck-regulator) is notoriously noisy and weak compared to an ESP32 board’s dedicated LDO/buck converter, especially if long DuPont jumper wires add series resistance/inductance.
Add a decoupling cap right across 3.3v & GND on the pie. See if it blinks. that will tell you power or signal forsure.
PJ 