search

sparkfunX / SparkFun_ESP32_Thing_Plus_C

USB C ESP32 Thing Plus
Other
12 stars 4 forks source link

Change the RGB LED pin - to avoid a clash with SDIO #5

Open idea--list opened 2 years ago

idea--list commented 2 years ago

Hooked up this board with an external uSD slot wired up for SDIO 4-bit mode as i was looking for high data rates. On the ESP32 chip GPIO_2 and GPIO_7 have SD_DATA0 functionality. On this board the RGB LED occupies GPIO_2. GPIO_7 is not broken out. This is really unfortunate as this way we can not interface an SD card neither in SDIO 1-bit nor in SDIO 4-bit modes.

If the RGB LED would occupy either an SD_DATA1 or SD_DATA2 capable pin, we could use at least SDIO 1-bit mode (which needs SD_DATA0 and SD_DATA3) Best would be however the RGB LED taking away any pin that is not needed for SDIO and all SDIO relevant pins should be broken out on the header when this becomes a red board.

UPDATE: Or change the MCU to an ESP32S3, as that chip can provide SDIO functionalities on any pins (just tested SDIO 4-bit mode works on that MCU no matter which pin headers i connect to the slot)

PaulZC commented 2 years ago

Hi Peter (@idea--list ),

This is a good suggestion - thank you. We will make note of this for future boards and revisions.

Forgive me for asking, but have you tried to use SDIO on this board? Yes, the RGB LED is connected to GPIO_2 but the LED is just an input. I suspect that SDIO may still work? OK, yes, the LED will be very confused and may show very random colors. But does it actually stop SDIO from working?

Many thanks, Paul

idea--list commented 1 year ago

@PaulZC Was away for some time...

Just tried to test it once more. Wrote some code in ESP-IDF to try different modes of SD-card connection. This particular board uses the VSPI pins of the MCU to connect to the on-board uSD-slot, which is working as expected. Using the HSPI pins i also connected an external uSD slot, which is also working fine in SPI mode. Yes, the RGB LED is occupying GPIO2 but the test point centrally from pin 4 seems to be the connection to the RGB LED. So while the external uSD slot is active, the RGB LED lights up in different colors.

However as soon as i switch to SDIO1 or SDIO4 modes i get this message in ESP-IDF: E (6049) sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107 E (6050) vfs_fat_sdmmc: sdmmc_card_init failed (0x107). [ 6053][E][SD_MMC.cpp:138] begin(): Failed to initialize the card (0x107). Make sure SD card lines have pull-up resistors in place.

On my Wemos Lolin D32 and Adafruit Feather ESP32S3 boards even SDIO1 and SDIO4 modes work as expected, so i guess the RGB LED affects the pullups-check in ESP-IDF. Or maybe also this relates to #2.

This issue became less relevant for me since the Thing Plus Dual-Port Logging Shield has been released. Will absolutely need to buy some!

PaulZC commented 1 year ago

Hi Peter (@idea--list ),

Many thanks for the feedback - we really appreciate it.

We have two new boards in the pipeline: a tweaked version of this Thing Plus C; and a new ESP32-WROOM-based board with microSD. The first won't support full SDIO as the changes would have been too drastic. For the second, I've designed in 4-bit SDIO from the start. It has the required pull-ups, plus isolation on the strapping pins so the pull-ups (which could be pull-downs if the microSD is deenergized!) won't interfere with the boot process.

Let me know how you get on with the dual-port shield. That was a fun design to work on! The first batch sold out really quickly. It should be back in stock soon.

Very best wishes, Paul