ESP32 - EN pin and the flashing issues, etc

[mikes_md]

30AWG is something like 320milliohms/m resistance, so even a fairly short length of wire has significant resistance compared to a small ceramic cap's ESR (remember the effective length is doubled due to power/ground both being wired this way). I would bet money this is why the ESP32 is randomly failing during flash operations (which require small bursts of power consumption), and adding the transistor-driven input to EN inadvertently improves the power supply by connecting a second parasitic power wire via the EN pin

So, I did read some more discussions and threads, and understand a bit more about the current bursts that occur during certain events (ie wi-fi things and flash operations), so maybe there is indeed a vdd rail lag in my test setup when it was in this 'failing' state..

So if we go with this theory...in my setup with the transistor, the second 'wire' from 3.3V vdd is only going to the npn collector...the GPIO is going to the base through a 1k resistor...

I'm not sure i see how the esp32 Vdd could see this setup as a parasitic voltage source? Unless you are saying 'internally' in the ESP32 core it is able to pull current through the EN pin?

Do you know exactly how the logic is designed internally in the ESP32 core, is 'CHIP_PU' just a single connection to the internal LDO 'enable' pin, and that's it?


Also, don't forget, one of the tests I did, when it was in this failing state, was I shorted (right on the ESP32 pads), Vdd to EN.. and the failures went away (this was when En was still just pulled up via 10k res)...

[ESP_Angus]

The extra low impedance current source is from 3.3V, through the CE junction of the switched on transistor (when STM GPIO enables it), into the EN pin. So when the transistor is on, it's similar (not the same as the transistor is not perfect) to shorting EN to 3.3V.

The EN pin is not a current sinking pin by design. However, almost any chip (from any vendor) will parasitically power itself from an input pin if the voltage at that pin goes high enough above the voltage at the VDD pin (maybe not power it reliably, and it may damage the chip, but some current will flow). If there's a temporary voltage dip on the main VDD pin (due to it being a poor quality input current source with relatively high resistance) then it's possible that the voltage at the EN pin will go above the threshold for input protection (relative to the dipping voltage at the VDD pin) and some current will flow into the ESP32's internal VDD power rail this way, keeping the voltage from dropping further during the brownout/glitch.

(If you have a 10K pullup this can't happen, because of the resistor.)

I'm not saying this is definitely happening. I'm saying it's possible it might be happening, and I've seen similar things happen by accident when wiring chips up (not just ESPs).

[mikes_md]

Ahh...

I gotcha, you are talking about input 'diode clamping'.. yeah, most chip manufacturers tend to do that today..

that could certainly be a scenario, I'll have to scope it up once I build my new board, and I take this current one off my rig, I can then keep it as is, scope the vdd line, etc, see if I see any sagging..

and also revert it to the original setup that failed, and observe that as well...

[ESP_Angus]

I gotcha, you are talking about input 'diode clamping'.. yeah, most chip manufacturers tend to do that today..

Yes. The input protection circuit on ESP32 is actually not diode clamping but a similar circuit (I think it's a snapback to the voltage rail), but essentially the same effect.

[mikes_md]

Hi Angus,


Just wanted to let you know, we can close this thread is solved, as I assembled my latest board, with the esp32 now routed onto the board.

I did a test by just having the EN pin driven by the STM32 GPIO pin directly (with no transistor or other components in the path), and everything worked perfect, flashing worked fine with NO errors whatsoever.

So it must have been as you said, related to that temp setup I had on the prior board, where I had to wire it up with short 30AWG wires.


But at least this will be good info for anyone that may encounter this if they do any type of breadboarding setup like this, where you may have current sag/etc..


Thanks again for your help on this,


- Mike

[Carlou]

I had the same issue that upload always ends up in an error and will never complete. I have also read the solution of putting a capacitor to the EN pin and ground. This solves the upload problem but disables the Bluetooth. So if you plan to use bluetooth which I did, then this is a No No solution. The last alternative I did but very annoying is to push the BOOT button while you uplaod. I hope ESPRESSIF will soon release an update to fix this cause the board is very nice to use but annoying to uplaod programs. By the way, I am using Arduino IDE in windows 10.