Really scratching my head here.
I am trying to start debugging on a ESP32 board with ESP-PROG debugger.
Platform autodetects the wrong upload port whatever I do. Even when I set the upload
port in in the platformio.ini file with upload_port = COM5 platformio is stubborn and keeps
picking the wrong port.
Manually selecting the upload port at the bottom left of the IDE window also doesn’t help.
Platformio sees the COM port and I can select the correct COM port, but again platformio
is stubborn is stubborn and keeps picking the wrong port…
I read previous forum posts on the subject and followed solutions offered there, but they
don’t work.
The error thrown in the terminal is: “A fatal error occurred: Failed to connect to ESP32: No serial data received.” which make sense because platformio is stubborn and only wants to pick COM6 while it needs to be COM5.
Does anyone know how to solve this?
Do you have multiple project folders in your VSCode workspace? See docs.
Thank you for helping!
I have only one workspace. Not sure what you mean by project folders (I am new to this).
This is what the explorer view shows:
Have you correctly configured the drivers for ESP-Prog on your computer? (I assume Windows)
Hi Vishnumaiea, also thanks for helping!
I think I configured the drivers correctly. I used the FTDI driver executable and after that used Zadig to install the winUSB driver…
Windows (you assumed correctly!) shows the COM ports correctly and in the driver details it shows that the devices are FTDI. When I try to upload (and platformio chooses COM6) I see the LED on the ESP PROG blinking…
I can only put one embedded media in a post so here is what windows show in the driver details:
Please show a full screenshot of VSCode with the failed upload message and the contents of the platformio.ini.
If the two ports are associated with ESP-Prog, then the drivers are not set up correctly. When you connect ESP-Prog to the PC, two device instances will be created. Instance 0 is used by JTAG and Instance 1 is used by a serial port (COM). Are you sure you replaced the driver for Instance 0 of the ESP-Prog?
Coincendatlly, I am also doing ESP32 debugging using ESP-Prog. The below screenshot shows the COM port generated by ESP-Prog.
The last 01 part says it is the instance used for serial communication. The JTAG port should appear as Dual RS232-HS on your device manager under Universal Serial Bus devices.
Once you set that correctly, PIO can detect the port correctly. You don’t need to specify a COM port for that.
I watched a video by Dave’s garage. He mentioned something about a USB Serial Converter A and USB Serial Converter B device. After Zadig was done the A device should be gone. I checked my device manager and saw the A device so I re-ran Zadig. After Zadig, the A device was gone and the view looked like this:
I tried to upload the code again and platformio still does auto-select (whilst I have the upload_port = COM5 line in the .ini) and it chooses the wrong port (COM6).
Which upload protocol are you using? If possible, you should post the platformio.ini file.
Thanks a lot for helping vishnumaiea!
here is the .ini file
Further info:
I did a reboot of the PC. The device manager keeps showing the Dual RS232-HS device so that is still good. In platformio I don’t see the COM5 port anymore, only COM6.
Comment out the upload_port line. Otherwise, it will confuse PIO because we won’t be using a COM port for uploading with esp-prog protocol (JTAG actually).
No that platformio.ini does not work at all. The native environment compiles for your native computer (that’s what platform = native is). Are there multiple environments ([env:xxxx]) defined in the platformio.ini? One that has platform = espressif32? You need to put the upload_port expression under the env for the ESP32.
@vishnumaiea I commented out the upload_port line. Unfortunately platformio still wants to use COM6.
@maxgerhardt there are not multiple environments defined. Also this project generates correct ESP32 code when I upload via the CP2102 on the target board. The project is for multiple targets which are defined above the previous screenshot. I think this is how the compilation for ESP32 is managed:
To explain a bit more (and maybe this is where the problem is): I am building a project called “Unified_ESP32_900_RX_via_UART”. So probably the clue is in the title: UART! I have screenshotted the section of the .ini file regarding the project name below:
I don’t understand everything, but I don’t see a reference to an upload via UART. Do you have a clue?
I modified the env:Unified _ESP32_900_RX_via_UART section with upload_port = COM5 (see below).
Now I see that the IDE tries to upload to COM5, but the COM5 port does not exist…
I see that environment extens another environment. The ini file for that environment shows this:
# ------------------------- COMMON ENV DEFINITIONS -----------------
[env]
#upload_port =
#upload_speed =
framework = arduino
extra_scripts =
pre:python/build_flags.py
python/build_env_setup.py
monitor_dtr = 0
monitor_rts = 0
[common_env_data]
build_src_filter = +<*> -<.git/> -<svn/> -<example/> -<examples/> -<test/> -<tests/> -<*.py> -<*test*.*>
build_flags = -Wall -Iinclude
build_flags_tx = -DTARGET_TX=1 ${common_env_data.build_flags}
build_flags_rx = -DTARGET_RX=1 ${common_env_data.build_flags}
[radio_900]
build_flags = -DRADIO_SX127X=1
lib_ignore = SX1280Driver
[radio_2400]
build_flags = -DRADIO_SX128X=1
lib_ignore = SX127xDriver
# ------------------------- COMMON ESP32 DEFINITIONS -----------------
# platform 5.1.0 uses arduino core 2.0.4 which has a "major" problem with
# requiring the QIO bootloader on PICO devices, so upgrading older firmware
# will be problem using OTA, unless we have a mechanism for uploading a new
# bootloader first!
[env_common_esp32]
platform = espressif32@5.2.0
board = esp32dev
board_build.partitions = min_spiffs.csv
upload_speed = 460800
monitor_speed = 460800
upload_resetmethod = nodemcu
board_build.f_cpu = 240000000L
extra_scripts =
${env.extra_scripts}
pre:python/build_html.py
build_flags =
-D PLATFORM_ESP32=1
-D CONFIG_TCPIP_LWIP=1
-D BEARSSL_SSL_BASIC
-D CONFIG_DISABLE_HAL_LOCKS=1
-I ${PROJECTSRC_DIR}/hal
build_src_filter = ${common_env_data.build_src_filter} -<ESP8266*.*> -<STM32*.*>
lib_deps =
makuna/NeoPixelBus @ 2.7.0
ottowinter/ESPAsyncWebServer-esphome @ 3.0.0
lemmingdev/ESP32-BLE-Gamepad @ 0.5.2
h2zero/NimBLE-Arduino @ 1.4.1
bblanchon/ArduinoJson @ 6.19.4
oled_lib_deps =
${env_common_esp32.lib_deps}
olikraus/U8g2 @ 2.34.4
tft_lib_deps =
${env_common_esp32.lib_deps}
moononournation/GFX Library for Arduino @ 1.2.8
[env_common_esp32rx]
platform = espressif32@5.2.0
board = esp32dev
board_build.partitions = min_spiffs.csv
upload_speed = 460800
monitor_speed = 420000
upload_resetmethod = nodemcu
board_build.f_cpu = 240000000L
extra_scripts =
${env.extra_scripts}
pre:python/build_html.py
build_flags =
-D PLATFORM_ESP32=1
-D CONFIG_TCPIP_LWIP=1
-D BEARSSL_SSL_BASIC
-D USE_MSP_WIFI=1
-D CONFIG_DISABLE_HAL_LOCKS=1
-I ${PROJECTSRC_DIR}/hal
build_src_filter = ${common_env_data.build_src_filter} -<ESP8266*.*> -<STM32*.*>
lib_deps =
makuna/NeoPixelBus @ 2.7.0
ottowinter/ESPAsyncWebServer-esphome @ 3.0.0
bblanchon/ArduinoJson @ 6.19.4
roboticsbrno/ServoESP32 @ 1.0.3
dlloydev/ESP32 ESP32S2 AnalogWrite @ 3.0.3
Okay, but then you definitely have found the right place to insert the upload_port command. But COM5 used to exist a while ago? Now there’s only one COM port? (This being an ESP-PROG is also what I expect if you’ve reconfigured it so that one channel is the JTAG and the other one the UART, per e.g. this article).
@maxgerhardt yeah, the COM5 is no longer there so it appears that the JTAG debugger is now correctly configured in windows. I will check if I can get the debugger working correctly now…
