E-Paper Calendar V2: Case Closed! The Price of Octal PSRAM

This article is generated by Gemini 2.5 pro.

---

(This post continues the debugging saga from the previous article.)

Remember the spooky “SPI initialization kills Wi-Fi” issue I mentioned in my last post? Even though I bypassed it with a software workaround (keeping SPI de-initialized by default), I still had this nagging feeling of “unfinished business.”

As an engineer, continuing development without knowing the Root Cause is like building a skyscraper on a tilted foundation. You never know when the next weird bug will bring it all down.

So, I decided to pause new feature development and launch a full investigation.

AI Might Send You on a Detour: Gemini’s Deep Analysis

I first asked Gemini for a deep dive. It produced an impressive, highly technical report listing three prime suspects:

1. Clock Gating Conflict: SPI2 might be accidentally toggling the LCD_CAM clock.
2. Bus Contention: SPI and Wi-Fi fighting for limited DMA channels.
3. Task Starvation: SPI interrupts hogging the CPU core, starving the Wi-Fi task.

It sounded plausible. I spent quite a while testing the suggestions—switching to SPI3, manually assigning DMA channels, and even completely disabling DMA (SPI_DMA_DISABLED). The result? Nothing worked. The system still hung.

Is the Chip Broken?

After all software solutions failed, I started suspecting the hardware. The ESP32-S3 on this board was salvaged from an old PCB using a hot air gun, and I knew it already had some leakage issues. I wondered: Is the chip just damaged internally?

Just as I was about to swap the chip, I casually asked Gemini: “Is there any other possibility?”

Unexpectedly, it threw out a keyword I had completely ignored: Octal PSRAM.

The Truth: GPIO 33-37 Conflict

My module is the ESP32-S3-WROOM-1-N16R8. The R8 stands for 8MB of Octal (8-line) PSRAM. To achieve high speeds, Octal PSRAM mandatorily occupies GPIO 33 through GPIO 37.

I looked back at my schematic:

• SPI MOSI: Connected to GPIO 35
• SPI CLK: Connected to GPIO 36
• EPD CS: Connected to GPIO 37

Bingo.

This wasn’t a DMA conflict or clock issue. When my code ran spi_init, I was literally cutting the physical connection between the CPU and the PSRAM. Since the Wi-Fi stack relies on PSRAM, the moment the line was cut, the system went brain-dead.

Verification and Solution

To prove this theory, I simply disabled PSRAM via menuconfig. I re-flashed the board… and it worked! Wi-Fi connected, HTTP requests succeeded, everything ran smoothly.

The Plan Forward

Now that the culprit is found, the path is clear:

1. Short Term: I will continue development with PSRAM disabled. My current memory usage is manageable with just the internal SRAM.
2. Hardware Adjustment: I wasn’t sure if I needed 8MB of RAM anyway. If I don’t, I can switch to the R2 (2MB PSRAM) module. The R2 version uses Quad SPI, which does not occupy GPIO 33-37. This would solve the conflict without changing the PCB layout and save some cost.
3. Worst Case: If I absolutely need 8MB PSRAM, I’ll have to spin a V2.2 hardware revision to reroute the SPI pins.

It was a long detour, but I sleep better knowing the root cause. Development should be much more stable from here on out!