Issue with GPIO12 and bootstrapping -- why is this happening?

[aekalman]

Hi All.

Am using a SparkFun ESP32 Thing as a development platform, have been successfully working with it for 6 weeks or so. The Thing is plugged into our own board, which has stuff like an SD Card socket, Ethernet PHY, I2C peripherals, etc.

During that time, GPIO12 (which is a bootstrap pin that controls VDD_SDIO) has been pulled up to 3.3V via 51k, since I was using GPIO12 as HS2_DAT2 (i.e., the DAT2 line in a 4-wire, high-speed SDMMC interface). It all works great.

Now, I have encountered a problem that doesn't make sense to me. I have switched from 4-line to 1-line SDMMC mode, because I need to free up two lines from the 4-line SD Card interface (GPIO4 & GPIO12) to be used as an I2C pair. I need to use these two lines because all of my other available GPIO is consumed by the Ethernet PHY. By switching to 1-line SDMMC, now I can run Ethernet PHY, 1-line SDMMC and I2C simultaneously.

In order to use GPIO4 and GPIO12 for I2C, they need to have 1.5k pullups to 3.3V. But, with these pullups in place, I can no longer successfully boot. I get this sort of message at boot:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x32 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>

Yes, I read https://github.com/espressif/esp-idf/issues/113 but I think this is a hardware problem.

I have confirmed that with the SparkFun ESP32 Thing alone, I can still boot, but when I plug into our board, I get this boot problem. The only substantive difference is the presence of 1.5k pull-ups on GPIO4 & GPIO12. For reference, a good boot (i.e., with no 1.5k pullups on GPIO4 and GPIO12) looks like this:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5760
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:13332
entry 0x40078fc8
[1B][0;32mI (55) boot: Detected ESP32[1B][0m
[1B][0;32mI (34) boot: ESP-IDF v3.0-dev-1117-gabacf8d2-dirty 2nd stage bootloader[1B][0m
[1B][0;32mI (34) boot: compile time 01:44:52[1B][0m
[1B][0;32mI (44) boot: Enabling RNG early entropy source...[1B][0m
[1B][0;32mI (44) boot: SPI Speed      : 40MHz[1B][0m
[1B][0;32mI (44) boot: SPI Mode       : DIO[1B][0m
[1B][0;32mI (48) boot: SPI Flash Size : 4MB[1B][0m
[1B][0;32mI (52) boot: Partition Table:[1B][0m
[1B][0;32mI (56) boot: ## Label            Usage          Type ST Offset   Length[1B][0m
[1B][0;32mI (63) boot:  0 nvs              WiFi data        01 02 00009000 00006000[1B][0m
[1B][0;32mI (71) boot:  1 phy_init         RF data          01 01 0000f000 00001000[1B][0m
[1B][0;32mI (78) boot:  2 factory          factory app      00 00 00010000 00100000[1B][0m
[1B][0;32mI (86) boot: End of partition table[1B][0m
[1B][0;32mI (90) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0d284 ( 53892) map[1B][0m
[1B][0;32mI (118) esp_image: segment 1: paddr=0x0001d2ac vaddr=0x3ffb0000 size=0x021e4 (  8676) load[1B][0m
[1B][0;32mI (121) esp_image: segment 2: paddr=0x0001f498 vaddr=0x40080000 size=0x00400 (  1024) load[1B][0m
[1B][0;32mI (125) esp_image: segment 3: paddr=0x0001f8a0 vaddr=0x40080400 size=0x00770 (  1904) load[1B][0m
[1B][0;32mI (134) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x23f3c (147260) map[1B][0m
[1B][0;32mI (193) esp_image: segment 5: paddr=0x00043f5c vaddr=0x40080b70 size=0x099f0 ( 39408) load[1B][0m
[1B][0;32mI (210) esp_image: segment 6: paddr=0x0004d954 vaddr=0x400c0000 size=0x00000 (     0) load[1B][0m
[1B][0;32mI (216) boot: Loaded app from partition at offset 0x10000[1B][0m
[1B][0;32mI (216) boot: Disabling RNG early entropy source...[1B][0m
[1B][0;32mI (219) cpu_start: Pro cpu up.[1B][0m
[1B][0;32mI (223) cpu_start: Starting app cpu, entry point is 0x40080ee4[1B][0m
[1B][0;32mI (0) cpu_start: App cpu up.[1B][0m
[1B][0;32mI (233) heap_init: Initializing. RAM available for dynamic allocation:[1B][0m
[1B][0;32mI (240) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM[1B][0m
[1B][0;32mI (246) heap_init: At 3FFB2C60 len 0002D3A0 (180 KiB): DRAM[1B][0m
[1B][0;32mI (252) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM[1B][0m
[1B][0;32mI (259) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM[1B][0m
[1B][0;32mI (265) heap_init: At 4008A560 len 00015AA0 (86 KiB): IRAM[1B][0m
[1B][0;32mI (271) cpu_start: Pro cpu start user code[1B][0m
[1B][0;32mI (289) cpu_start: Starting scheduler on PRO CPU.[1B][0m
[1B][0;32mI (0) cpu_start: Starting scheduler on APP CPU.[1B][0m

Now, if my 4MB external flash (which is all the flash that the SparkFun ESP32 Thing has) was powered from VDD_SDIO, then I could believe that the pull-up at boot on GPIO12 was perhaps causing a flash read problem. But on the SparkFun ESP32 Thing, the flash chip's power pin is hard-wired to 3.3V -- so it isn't using VDD_SDIO.

It's as if there is some other block of Flash / code that might be affected by the bootstrapped GPIO12 pin being held high (we can presume that the pull-down inside the ESP32 is weaker than my external 1.5k pull-up).

In summary:

• I am using external flash
• My external flash is powered from 3.3V, and not VDD_SDIO
• I have 1.5k pullups to 3.3V on GPIO4 and GPIO12
• When these pullups are present, I cannot boot successfuly

Any help in figuring this out would be appreciated.

Thanks!

[ESP_Sprite]

GPIO12 doesn't just affect the output of VDD_SDIO, it also affects the output of the GPIOs that connect to the flash (they will output 0-1.8V instead of 0-3.3V). That's probably why the device won't boot with 3.3K pull-ups. I think with the 51K pull-up, the internal pulldown just happened to be stronger than the 51K resistor, hence it worked fine with only that in place.

[aekalman]

Hmmm ... that would make sense -- I had not thought of that. I don't recall see the manuals say that the SDIO interface goes to 1.8V I/O levels in that case (just that VDD_SDIO is sourced from the internal 1.8V regulator) -- but that would make sense.

Yes, I figured there was a weak pull-up issue in all of this, which is why the 51k pullups on the SD Card were not causing problems. Although I would expect 51k to be stronger than any pull-up/pull-down inside the ESP32.

Thanks, I will follow up.