Need help to download firmware into ESP32

[andyman]

Anyone know if there is a way to download Arduino IDE code to ESP32 using an external USB-Serial converter connected to GPIO17(Rx1) and GPIO16(Tx1) ( instead of the default GPIO1(TX0) and GPIO3 (RX0) ) . I think the RX0 pin on my ESP32 is damaged and stuck high at 3.3v during the download phase.

[Ritesh]

Anyone know if there is a way to download Arduino IDE code to ESP32 using an external USB-Serial converter connected to GPIO17(Rx1) and GPIO16(Tx1) ( instead of the default GPIO1(TX0) and GPIO3 (RX0) ) . I think the RX0 pin on my ESP32 is damaged and stuck high at 3.3v during the download phase.

Hi,

There is one way to change or update those UART settings using which you can change those RX and TX related changes.

Go to make menuconfig ---> Component config ---> ESP32-specific ---> UART for console output (Default: UART0, TX=GPIO1, RX=GPIO3) --->

So, you can change those settings as per your requirement but make sure that other GPIOs should be free which you will choose for that purpose.

Let me know if need any other help for that.

[andyman]

Ritesh, I am up and running again. Thanks for your help.

[cmorgan]

Answering my own problem, I found that the difference between the USB->UARTs was how they handled a block of characters sent in sequence (so probably something related to buffering in them). My advice to others would be to loop back TX to RX and then compare what esptool was was trying to send, to what was actually going down the serial line. Shockingly mine was dropping characters when esptool sent a block all at once. Typing on a keyboard was slow enough for it not to be a problem.

I'm seeing the same thing here. Works great on the same board via usb->serial CP2101 chip but not via the FTDI TTL-232R cable on the same signal lines.

Did you end up slowing the communications down and getting it working? What USB->UART were you using that didn't work?

[mickeypop]

ESP_Angus is right.
Almost all FTDI chips can only supply 50mA, so when the WiFi goes live the BROWN OUT happens.

On the FTDI there is usually a voltage select jumper 3.3V/5V.
I piggy backed a LM1117-3.3 and tied the center pin to the LM1117 output (no more jumper) and brownouts stop since the 1117 can drive around 600mA.

As to flashing;
Look at the 2 NPN, 2 resistor circuit on any USB programmable board.
The 3.3v,tx,rx,DTR are on any FTDI board output pins, however not every board brings out the RTS.
It on the chip, just connect to it.
You will need to connect it to make the auto flash work.
Just wire up any NPN pair between the FTDI and the ESP32 for the auto programming.

[cmorgan]

ESP_Angus is right.
Almost all FTDI chips can only supply 50mA, so when the WiFi goes live the BROWN OUT happens.

On the FTDI there is usually a voltage select jumper 3.3V/5V.
I piggy backed a LM1117-3.3 and tied the center pin to the LM1117 output (no more jumper) and brownouts stop since the 1117 can drive around 600mA.

As to flashing;
Look at the 2 NPN, 2 resistor circuit on any USB programmable board.
The 3.3v,tx,rx,DTR are on any FTDI board output pins, however not every board brings out the RTS.
It on the chip, just connect to it.
You will need to connect it to make the auto flash work.
Just wire up any NPN pair between the FTDI and the ESP32 for the auto programming.

That is a good point. In the current rev of my board I haven't wired up DTR and RTS on the header, those go to testpoints but not to the npns like the same signals from the usb connector.

One other point is that I do have 100 ohm current limiting resistors on each signal. I don't think this should be a problem but wanted to bring it up.

Shouldn't I be able to program without DTR and RTS signals? If I follow a process like:

- Press boot
- Press en
- Release en
- Release boot
- Run 'make flash' from the terminal with the FTDI TTL-232R device

At this point I see the connecting output with ...____...___...___ etc and it fails.

If I repeat button process above while connected via 'make monitor' or 'make simple_monitor' I see from the esp32 something like "Waiting for download" which appears to indicate the device is in the correct mode, but it won't program when in this mode via 'make flash'.

Is esptool looking for the state of one of those hardware flow control lines before starting?