Connection problem - failed uploading /dev/cu.usbserial

After a year I wanted to compile and run a project again. The board type I’m assuming is an ESP32-WROOM-32. Did not find an exact match by name/designation. Chose ESP32-WROOM-DA.

Btw, a side question: why does the filter in the board chooser not work as one would expect? You see a long alphabetically sorted list of boards starting with letter “a”. Entering a pattern, like “ESP” doesn’t change the filtered list. One still has to scroll down to letter E… to get to the list of ESP-Boards.

Anyway, back to the actual connection problem:

Connected to ESP32 on /dev/cu.usbserial-141410:
Chip type: ESP32-D0WD-V3 (revision v3.1)
Features: Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency: 40MHz
MAC: 1d:8f:fe:92:11:32

Uploading stub flasher...
Running stub flasher...
Stub flasher running.
Changing baud rate to 921600...
Changed.

Hard resetting via RTS pin...
Failed uploading: uploading error: exit status 2

Do an upload with Verbose enabled in prefs and post the ENTIRE log in code tags < CODE/ >

Sketch uses 341219 bytes (26%) of program storage space. Maximum is 1310720 bytes.
Global variables use 25504 bytes (7%) of dynamic memory, leaving 302176 bytes for local variables. Maximum is 327680 bytes.
"/Users/kuku/Library/Arduino15/packages/esp32/tools/esptool_py/5.1.0/esptool" --chip esp32 --port "/dev/cu.usbserial-141410" --baud 921600  --before default-reset --after hard-reset write-flash  -z --flash-mode keep --flash-freq keep --flash-size keep 0x1000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.bootloader.bin" 0x8000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.partitions.bin" 0xe000 "/Users/kuku/Library/Arduino15/packages/esp32/hardware/esp32/3.3.6-RC1/tools/partitions/boot_app0.bin" 0x10000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.bin"
esptool v5.1.0
Serial port /dev/cu.usbserial-141410:
Connecting....Traceback (most recent call last):
File "esptool/init.py", line 1173, in _main
File "esptool/init.py", line 1032, in main
File "esptool/cli_util.py", line 229, in call
File "rich_click/rich_command.py", line 404, in call
File "click/core.py", line 1442, in call
File "rich_click/rich_command.py", line 187, in main
File "click/core.py", line 1830, in invoke
File "click/core.py", line 1226, in invoke
File "click/core.py", line 794, in invoke
File "click/decorators.py", line 34, in new_func
File "esptool/init.py", line 688, in write_flash_cli
File "esptool/cmds.py", line 1112, in attach_flash
File "esptool/loader.py", line 1091, in flash_id
File "esptool/loader.py", line 1653, in run_spiflash_command
File "esptool/loader.py", line 901, in read_reg
File "esptool/loader.py", line 565, in check_command
File "esptool/loader.py", line 495, in command
File "esptool/loader.py", line 431, in read
StopIteration

A fatal error occurred: The chip stopped responding.

Connected to ESP32 on /dev/cu.usbserial-141410:
Chip type:          ESP32-D0WD-V3 (revision v3.1)
Features:           Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency:  40MHz
MAC:                xxxxxx

Uploading stub flasher...
Running stub flasher...
Stub flasher running.
Changing baud rate to 921600...
Changed.

Hard resetting via RTS pin...
Failed uploading: uploading error: exit status 2

OK, I remebered that changing the upload speed could help. It then worked. At least the upload finished but the program doesn’t start. Last message I’m getting is:

”Hard resetting via RTS pin”

Looks like a Mac. Are you Silicon? If so did you install Rosetta?
Did you enable Verbose?

Yes I enabled “Verbose” on upload.

Rosetta? Don’t know what this is.

Apple MBP 11,2, Sequoia 15.7.3, Intel, OCLP

Rosetta allows you to run Intel code on Apple Silicon but I see you are an older Intel MBP. I have never seen upload output like that. If it happened twice, you need to replace esptool/loader.py. The easiest way to do that is simply re-install the IDE on top of your existing IDE.

Thanks. Will do a re-install of the IDE

1 Like

Let us know if that fixes it and if so mark post 6 as the solution.

Ah, I see. Forgot, Rosetta, yes, rings a bell. But since I have Intel architecture this never was in the focus to me :slight_smile:

And I’m at downloading the IDE 2 now and will report.

EDIT: the download has finished. I didn’t uninstall anything, just copied over the package into the Applicatios Folder…

OK, the OS noticed that a newly downloaded app from the Internet was there and checked it as a sign I actually was using something new. But the picture is the same:

Sketch uses 341219 bytes (26%) of program storage space. Maximum is 1310720 bytes.
Global variables use 25504 bytes (7%) of dynamic memory, leaving 302176 bytes for local variables. Maximum is 327680 bytes.
"/Users/kuku/Library/Arduino15/packages/esp32/tools/esptool_py/5.1.0/esptool" --chip esp32 --port "/dev/cu.usbserial-141410" --baud 115200  --before default-reset --after hard-reset write-flash  -z --flash-mode keep --flash-freq keep --flash-size keep 0x1000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035Dxxxxxxxxxxxxx16CF6/ESP32_TOF_Multi.ino.bootloader.bin" 0x8000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.partitions.bin" 0xe000 "/Users/kuku/Library/Arduino15/packages/esp32/hardware/esp32/3.3.6-RC1/tools/partitions/boot_app0.bin" 0x10000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.bin"
esptool v5.1.0
Serial port /dev/cu.usbserial-141410:
Connecting....
Connected to ESP32 on /dev/cu.usbserial-141410:
Chip type:          ESP32-D0WD-V3 (revision v3.1)
Features:           Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency:  40MHz
MAC:                xxxxxxxx

Uploading stub flasher...
Running stub flasher...
Stub flasher running.

Configuring flash size...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00063fff...
Compressed 25184 bytes to 16076...

Writing at 0x00001000 [                              ]   0.0% 0/16076 bytes...

Writing at 0x00007260 [==============================] 100.0% 16076/16076 bytes...
Wrote 25184 bytes (16076 compressed) at 0x00001000 in 1.7 seconds (116.6 kbit/s).
Hash of data verified.
Compressed 3072 bytes to 146...

Writing at 0x00008000 [                              ]   0.0% 0/146 bytes...

Writing at 0x00008c00 [==============================] 100.0% 146/146 bytes...
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.0 seconds (711.9 kbit/s).
Hash of data verified.
Compressed 8192 bytes to 47...

Writing at 0x0000e000 [                              ]   0.0% 0/47 bytes...

Writing at 0x00010000 [==============================] 100.0% 47/47 bytes...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (1540.5 kbit/s).
Hash of data verified.
Compressed 341360 bytes to 190236...

Writing at 0x00010000 [                              ]   0.0% 0/190236 bytes...

Writing at 0x0001b834 [=>                            ]   8.6% 16384/190236 bytes...

Writing at 0x0002b54e [====>                         ]  17.2% 32768/190236 bytes...

Writing at 0x00030de1 [======>                       ]  25.8% 49152/190236 bytes...

Writing at 0x000365e4 [=========>                    ]  34.4% 65536/190236 bytes...

Writing at 0x0003bff7 [===========>                  ]  43.1% 81920/190236 bytes...

Writing at 0x00041293 [==============>               ]  51.7% 98304/190236 bytes...

Writing at 0x00046844 [=================>            ]  60.3% 114688/190236 bytes...

Writing at 0x0004bef5 [===================>          ]  68.9% 131072/190236 bytes...

Writing at 0x00054612 [======================>       ]  77.5% 147456/190236 bytes...

Writing at 0x0005a089 [========================>     ]  86.1% 163840/190236 bytes...

Writing at 0x0005fd40 [===========================>  ]  94.7% 180224/190236 bytes...

Writing at 0x00063570 [==============================] 100.0% 190236/190236 bytes...
Wrote 341360 bytes (190236 compressed) at 0x00010000 in 18.9 seconds (144.6 kbit/s).
Hash of data verified.

Hard resetting via RTS pin...

Debugee is not started. I started it by clicking on the Debug-Button:

Waiting for gdb server to start...[2026-01-21T15:05:56.590Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
/Users/kuku/Library/Arduino15/packages/esp32/tools/openocd-esp32/v0.12.0-esp32-20251215/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /Users/kuku/Documents/Arduino/ESP32_TOF_Multi -f "/Applications/Arduino IDE.app/Contents/Resources/app/plugins/cortex-debug/extension/support/openocd-helpers.tcl" -f board/esp32-wrover-kit-3.3v.cfg
Open On-Chip Debugger v0.12.0-esp32-20251215 (2025-12-15-18:17)
Licensed under GNU GPL v2
For bug reports, read






DEPRECATED! use 'gdb port', not 'gdb_port'
DEPRECATED! use 'tcl port' not 'tcl_port'
DEPRECATED! use 'telnet port', not 'telnet_port'
CDRTOSConfigure
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Error: unable to open ftdi device with description '', serial '' at bus location '*'

[2026-01-21T15:05:56.863Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

Ok, it looks like that file was damaged and now is ok. Mark post 6 as the solution.

I have never used a debugger with Arduino code, so can't comment further.
Open a new topic for the debugger issue.

Actually I don’t want to use the debugger now. It would be sufficient, if my app would start on the target. But nothing happens. Is this

Hard resetting via RTS pin...

correct?

For the fun of it I switched to the Bluetooth serial port /dev/cu.Bluetooth-Incoming-Port :

Sketch uses 341219 bytes (26%) of program storage space. Maximum is 1310720 bytes.
Global variables use 25504 bytes (7%) of dynamic memory, leaving 302176 bytes for local variables. Maximum is 327680 bytes.
"/Users/kuku/Library/Arduino15/packages/esp32/tools/esptool_py/5.1.0/esptool" --chip esp32 --port "/dev/cu.Bluetooth-Incoming-Port" --baud 115200  --before default-reset --after hard-reset write-flash  -z --flash-mode keep --flash-freq keep --flash-size keep 0x1000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.bootloader.bin" 0x8000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.partitions.bin" 0xe000 "/Users/kuku/Library/Arduino15/packages/esp32/hardware/esp32/3.3.6-RC1/tools/partitions/boot_app0.bin" 0x10000 "/Users/kuku/Library/Caches/arduino/sketches/DCBA9035D28F74465AECB4FD32816CF6/ESP32_TOF_Multi.ino.bin"
esptool v5.1.0
Serial port /dev/cu.Bluetooth-Incoming-Port:
Connecting......................................
A fatal error occurred: Failed to connect to ESP32: No serial data received.
For troubleshooting steps visit: 


Failed uploading: uploading error: exit status 2

Yes, normal upload. Open the serial moniotor, that should be enough to start the sketch, if you don;t see output in a reasonable time, then click the reset button on the board.

Bluetooth is too slow and there are 4 kinds of Bluetooth, do you have the right one? Don;t ask me, I hate Bluetooth.

Thanks. The program is running. I made a mistake. All fine. And I dropped the BT attempt :)

1 Like