Can't upload to ESP32 when LED's are in circuit

I have been working with the ESP32 for about 6 weeks now, and I keep discovering things -- a real learning curve. However, today I tried attaching an bicolor LED to two pins, common anode, so the LED's are on when the pins are low. The LED lights up before the program is downloaded, so I assume the pins (GPOI 2 and GPIO 4) are low in their unprogrammed state.

Here's the rub. The code will not upload when the LED's are attached. ("Timed out waiting for packet content) I used a 1K resistor for current limiting, so only a few milliamps should be sunk by the ESP32 when the LED's are on. If I disconnect the LED's the code loads, and if I then reconnect the LED's the program functions fine.

I have tried this on the HelTec WiFi Kit 32, and another board from ezSBC. Same problem.

Any insights into this would be appreciated.

jrdoner

GPIO4 is also ADC CH0 is also TOUCH9 is also RTC_CPIO10
GPIO2 is also ADC CH2 is also TOUCH2 is also RTC_CPIO12

Do you think the secondary uses is the cause?

To the best of my knowledge, any GPIO pin can be used as a simple digital I/O pin. The Heltec board does reserve pins 4, 15, and 16 for the OLED. I also understand that the ADC2 circuitry is not available when WiFi is operational. Pins 4 and 2 are not attachable to ADC2. In any event, when uploading code, I would not expect any of the pins to be active at all, except Tx/Rx and maybe Reset. Somehow, this seems more like a power shortage problem, but I am using a 2 Amp 5v. source to power the boards.

jrdoner:
To the best of my knowledge, any GPIO pin can be used as a simple digital I/O pin.

To the best of my knowledge, that is just not true.

You need to be careful what you connect to various pins; some are input only, some dont have internal pullups, some are on (or off) during sleep, some pulse when going into sleep etc. Plus, what some pins are wired to can affect operation and program upload of the ESP32.

So what did you find happened;

  1. When the LEDs are attached to another pin and GPIO2 is left alone ?

  2. What happens to program upload, when nothing is connected and GPIO2 is connected to ground ?

  3. What happens to program upload, when nothing is connected and GPIO2 is connected to VCC ?

GPIO2 and 4 seem to be in the clear (I or O), but '2' is connected to the onboard LED.

runaway_pancake:
GPIO2 and 4 seem to be in the clear (I or O), but '2' is connected to the onboard LED.
ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials

I would not myself assume that lack of detail on a 'randomnerdtutorial' was proof of a lack of a problem.

Have you tried the tests suggested in post #3 ?

Yeah, ok, fine.
Then here's what.
I too (like you jrdoner) have an ezSBC ESP32 and I uploaded the following sketch, with the LEDs connected -- Zero Problems --

const uint8_t red2 = 2;
const uint8_t yel4 = 4;

void setup() 
{
  pinMode(red2, OUTPUT);
  pinMode(yel4, OUTPUT);
}
void loop() 
{
 digitalWrite(red2, HIGH);
 delay(1000);
 digitalWrite(red2, LOW);
 digitalWrite(yel4, HIGH);
 delay(1000);
 digitalWrite(yel4, LOW);
}

OK, interesting development.
I had the LED cathodes going to Ground.
When I reconfigured them, anodes to +3V, then it would not Upload.

P.E. When I disconnected them from +3, it Uploaded -- and with just GPIO4 LED in.
With only the GPIO2 LED connected it failed.

http://www.ezsbc.com/index.php/productattachments/index/download?id=30

So, with the Red to GPIO2 and Yellow to GPIO4, it won't Upload.
BUT. . .
with the Red to GPIO4 and Yellow to GPIO2, It Uploads.
(Red w/ 240Ω, Yel w/ 270Ω)

Ah, you discovered the problem at last.

GPIO2 must not be held high during upload .......................

Amazing how poor a lot of so called ESP32 'documentation' is, when it misses out real important stuff .............

But that isn't exactly so though.
It can be "held high" - but at some point it cannot.
As I noted in my previous, with the Yel+270Ω connected to GPIO2 it does Upload (whether the Red is on GPIO4 or not).

See pages 10 & 11 section 2.4

GPIO2 is a "strapping pin" (as are GPIO0, GPIO5 -- and MTDO and MTDI).

Sure, I found the 'odd' behaviour with GPIO2 quite some time back, and whilst the data sheet mentions that GPIO2 is a 'strapping pin', as does Kolbans manual, the implications are perhaps not made very clear.

At the time I made a note;

2 Output, shared with the LED on some boards. LED to ground OK, dont let pin be pulled high. Used by pSRAM option when fitted.