I just received two REV F boards from Mouser and I am having problems uploading on both. I am using an Ubuntu based distro and Arduino IDE v1.8.10. Sometimes it just works sometimes I have to try several times and on one of the boards currently I have not been able to upload for a few days. What is odd is the original firmware was easily uploaded over but my simple "Hello World" test are not. Is this a problem with talking on the same UART as the programmer is on causing some race condition?
Any suggestions appreciated.
RE
SM
Try the driver here: https://github.com/OLIMEX/ch340-dkms - follow the instructions.
Try to lower the upload speed.
Might be related to support of the software under your operating system. Worth checking the ESP32 package for Arduino forums and GitHub page for similar issues. It can be found here: https://github.com/espressif/arduino-esp32/issues
I observed the same behaviour with my rev F boards. I own no others to compare. The suggested driver (ch340-dkms) made no difference for me.
I use esp-idf. idf.py monitor works fine. idf.py flash monitor fails 95% of the time (timed out waiting for packet header). Independent of selected baudrate.
By pressing RST1-button I can force bootloader mode and flash successfully.
It seems something goes wrong with the RTS and DTR signals to automatically enter the bootloader mode.
Other possibly relevant observations:
- The first time flashing went smooth on both boards I own.
- The few times I used an old Lenovo laptop for flashing, it worked 100% of the time. A brand new HP Elitebook gives trouble. To be checked if it were lucky shots with the Lenovo.
Any suggestions to enable automatic bootloader mode for flashing are welcome!
I can confirm that the choice of laptop matters.
Flashing the ESP32-EVB works fine with a Lenovo Thinkpad E530, using any of the USB ports. The green led COMPLETE1 is on when plugged in the Lenovo blue USB3 ports and off in the yellow USB port.
Flashing the ESP32-EVB fails with a HP Elitebook 735 G6. The green led COMPLETE1 stays off in any of the HP ports.
Both systems run Nixos 19.09. The Lenovo was tested with kernels 4.19 and 5.5.7. The HP was tested with kernels 5.5.4, 5.5.6 and 5.5.7, with drivers ch341 and ch340-dkms. The results are independent of kernel version or driver.
When monitoring with 'idf.py monitor', bootloader mode can be requested by typing ctrl+T ctrl+P. That uses the RTS and DTR signals to pause the esp32 and get to the bootloader mode. This again works on the Lenovo and fails on HP. On HP it just reboots normally after the pause.
Do you have any suggestions how to investigate further or just make it work on the HP?
I suspect the 2 laptops have different USB hardware (*) internally and thus different drivers.
(*) er, I think the USB hub(s)
It's probably connected with that.
Whether a driver issue or h/w - can't even guess.
(Maybe also the current the ESP32 demands?)
John
This is interesting, but I am not sure if it is related to HP's USB. Maybe it is related to the ESP-IDF. Can you confirm the software setup is exactly the same between the two machines (ESP-IDF and its related tools are the same version)? It is worth also testing with Arduino for ESP32 on both machines - if it is related to the software such a test would show it.