I2C0 halts during Ethernet operation?

Question

Has anyone succeeded in running the Arduino SSD1306 OLED on I2C0 while Ethernet is operating? Our SSD1306 OLED display stops updating once Ethernet is up. Hardware: W55RP20-arduino SSD1306 on I2C0 GPIO4 and 5 Platform: Arduino/FreeRTOS Adafruit SSD1306 library is used. Thread SSD1306 is running on core 0 with priority 6. Thread Eth is running on core1 with priority 3. The SSD1306 updates every second when the Ethernet thread is stopped. The SSD1306 halts in display() when the Ethernet thread is started.

Lihan__ · Answer

Hi, Based on the symptoms — the OLED display Task halting the moment the Ethernet thread starts — I'd recommend checking these two things first. 1. Check whether the I2C0 pins (GPIO4, GPIO5) overlap with the W55RP20's internal SPI The W55RP20 is a SiP where the RP2040 and W5500 are connected internally through GPIOs, so the Ethernet driver has to drive the W5500 over PIO-based SPI. GPIO20–25 are reserved for that internal connection, which means GPIO4/5 should in principle be free. However, if the PIO program is misconfigured to claim GPIO4 or GPIO5, the conflict won't produce a compile error — it will only show up at runtime. That matches your symptom (the OLED Task halts as soon as Ethernet starts) exactly. Please verify on the schematic that GPIO4/5 aren't routed to anything Ethernet-related, and in firmware confirm that the PIO SPI pin range doesn't include GPIO4/5. 2. Check whether the Ethernet thread releases its mutex/semaphore often enough Even with the two Tasks pinned to different cores, shared resources can still stall the OLED Task. If the Adafruit SSD1306 library and the Ethernet driver share the same underlying resource inside the Arduino-Pico SDK (e.g., a global Wire lock), the Ethernet thread may be holding that mutex for long stretches without calling xSemaphoreGive() often enough. In that case, the OLED Task will sit waiting indefinitely due to priority inversion, even though it has the higher priority. Recommended checks: Add a short vTaskDelay() or taskYIELD() inside the Ethernet loop and see if the OLED Task recovers. Instrument the mutex/semaphore take/release calls and confirm that xSemaphoreGive() is called on every path, including error paths. Probe SDA/SCL with a logic analyzer to check whether the bus is actually being driven at the moment the Task hangs. Please rule out these two first, and let me know what you find — happy to dig deeper from there.