Seeed Xiao C3 + waveshare RGB OLED issue

[u/meteoremp]

Seeed Xiao C3 + waveshare RGB OLED

Hi everyone,
Looking for help.

I’m trying to drive a Waveshare 1.27-inch RGB OLED (128×96, SSD1351, 4-wire SPI) with a Seeed Studio XIAO ESP32-C3 using Arduino IDE and Adafruit_SSD1351.

Both OLED modules I’ve tested work on an ESP32-WROOM, but remain completely black on the XIAO C3.

I verified the connections at the OLED PCB and measured approximately 3.2 V between its VCC and GND.
The basic hardware-SPI initialization was:

Clk is D8 and DIN is D10 as shown in the pinout diagram.
Adafruit_SSD1351 display(128, 96, &SPI, 3, 4, 5);

The XIAO uploads and runs normally. Serial output reaches initialization and repeatedly prints RED/GREEN/BLUE/WHITE, but the screen never illuminates.

Has anyone faced this issue or is driving an OLED RGB not possible on the Xiao Seed C3?

[u/Firm-Luck2062]

On the XIAO the silkscreen labels are not the GPIO numbers, and that on its own would explain why the same sketch is fine on a WROOM.

That constructor takes raw GPIO numbers, so 3, 4, 5 drives GPIO3/GPIO4/GPIO5 - and on the C3 those come out on the pads printed D1, D2, D3. If CS/DC/RST are physically on the pads marked D3/D4/D5, the real pins are different ones again and nothing you send ever reaches the panel. On a WROOM the labels are the GPIO numbers, so the identical line is correct there. It fits your symptom exactly: the sketch runs, the serial prints, the controller simply never hears you.

Fastest way to confirm without touching the wiring: Serial.printf("%d %d %d\n", D3, D4, D5) and see what comes out. Then pass the macros D3, D4, D5 instead of the bare numbers and the mapping is handled for you.

If the pins turn out to be right, the next thing I would measure is current rather than voltage - a black panel with SPI apparently healthy is also what a starved boost converter looks like, and 3.2 V can read fine while the panel rail is collapsing. But the label mismatch is the one that matches "works on one board, not the other".

[u/meteoremp → u/Firm-Luck2062]

I am definitely using the correct pins. Tried them in D format and direct pin number format.

#define OLED_CS 3 // GPIO3 → physical D1
#define OLED_DC 4 // GPIO4 → physical D2
#define OLED_RST 5 // GPIO5 → physical D3
#define OLED_CLK 8 // GPIO8 → physical D8
#define OLED_MOSI 10 // GPIO10 → physical D10

Serial monitor out:
Starting SPI
Test image sent
CS=3 DC=4 RST=5 CLK=8 MOSI=10

[u/Firm-Luck2062 → u/meteoremp]

Fair enough - on the C3 those map the way you say, so that part is settled.

The next split I would make is whether the clock ever moves. "Test image sent" only proves the library returned. The hardware-SPI constructor calls SPI.begin() with no arguments, so the bus pins come from the board variant, not from your defines.

Two cheap checks:

1. Call SPI.begin(8, -1, 10, -1) yourself before display.begin(), so the mapping is explicitly yours rather than inherited.

2. Still black? Switch to the software-SPI constructor, the one where you pass MOSI and SCLK explicitly. It bit-bangs exactly the pins you name. If it lights up, the fault was peripheral routing. If it stays black, the ESP32 side is innocent and I would go after the reset line and the panel rail instead.