Excessive current on GPIO0 when driving to ground?

[guan]

I have ESP8266EX on a custom board that is intended to be programmed externally using the UART bootloader. On the board itself, I have:

• MTDO connected directly to GND.
• GPIO2, GPIO0, CH_PD and RST all pulled high with a 10K resistor each.

My strategy for programming is that I will use an external board that first asserts RST, then asserts GPIO0, then releases RST, which should start the UART bootloader.

Everything works. I am able to load a program, and then to boot into it (after releasing GPIO0).

However, I noticed that when shorting GPIO0 to ground, about 46 mA of current flows through. It seems like under this circumstance, GPIO0 is driven high by the chip, and I am shorting it out, with 46 mA being due to the current limit of the pin.

This is true even on a completely blank flash chip before I have done anything, using the board for the first time.

Am I observing something totally weird? I am not using GPIO0 in my application, so I don't particularly mind breaking it, as long as the input buffer doesn't break so I can still use the UART bootloader. And of course I don't want anything else in the chip to break due to the heat.

[Espressif_Kelly]

Dear Sir,

Before first software download, GPIO0 is an output pin by default.

If you short GPIO0 to ground, there should be about 46mA of current flows through which may be also the max output current.

If you turn off the output of GPIO0, there will be no excessive current.

Any more questions, please let us know.

Thanks for your interests in ESP8266EX!

[baoshi]

Currently I use a series resistor of 4.7K between GPIO0 and my controller board.
I pull RESET and GPIO0 down, wait 50ms, release RESET but continue pull down GPIO0, wait 20ms, then release GPIO0.
It seems the chip enters bootloader mode successfully.
The 50ms and 20ms are based on experiment. Actually I can see GPIO0 starts to output something about 15ms after RESET's rising edge.
Is there any officially recommended way of treating GPIO0 during firmware download?

Thanks

[YimingLi]

Hi,

GPIO0 is the boot_sel1, together with MTDO/boot_sel2 and GPIO2/boot_sel0 to form a boot mode selection array boot_sel[2:0], From the name you might figure out that the chip samples these pins upon bootup (excluding a reset by wdt) to select the boot mode -- as we know, if boot_sel[2:0]=b001, i.e. MTDO=0, GPIO0=0, GPIO2=1, the chip will select "booting from uart0", the mode in which we use to burn the flash.

That is, per your topic, what is important is the level of GPIO0 sampled in by the chip "during" reset out. However the GPIO0 levels before reset, in reset, and after reset out, are not important. Or we could say that, either "pull down GPIO0 -> pull down nRESET -> release nRESET -> release GPIO0" or "pull down nRESET -> pull down GPIO0 -> release nRESET -> release GPIO0" would both work to bring the chip into a mode of booting from UART, only if that the GPIO0 gets release to high after the nRESET gets released high.

However, since GPIO0 might be in GPIO output mode and output a high level by the firmware inside the chip before your extern control to pulldown the GPIO and nRESET. That is, you might encounter a risk that you are to pulldown the GPIO0 externally when the the chip firmware is outputing the GPIO0 high, which would bring about a large excessive current consumption, even you might cause the module fail to work. Considering At Reset the GPIO0 will be in output disabled mode (oe=0, wpu), it will be safer to pull down the GPIO0 externally after you pull down the nRESET.

Therefore, a better way to bring the chip into a mode "boot from uart" might be the latter one of above two, that is, "pull down nRESET -> pull down GPIO0 -> release nRESET -> release GPIO0".

About how long an interval you should give between the pull-downs and releases, this is something like a question about setup and hold time margins, and reset timings. There is no data for them from the datasheet. However in my opinion, it should be a possitive value at least observed from the two pins. That is, you should count in your code delay, output and transmission delay, stability margins etc. In my customized toolkits (sofware) for my customized esp8622ex module, it seems that an interval(given in software) of several ms between GPIO0 and nRESET, and tens of ms for reset period would work. Anyhow, the intervals are just used to bring the module/chip into a mode of "boot mode from uart", compared with the time required to burn the flash, does a delay of 100ms or 10ms make quite a difference? Therefore, I would give adequate intervals here to ensure a stable and enough timing margin.

Hope it would be helpful.