Issue with GPIO12 and bootstrapping -- why is this happening?
Posted: Fri Dec 15, 2017 10:52 am
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:
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:
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:
Thanks!
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
>
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
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
Thanks!