esp8266: struggling with flashing via esptool

[paule]

Dear comunity,

As written in subject, I'm facing problems uploading binaries to the esp8266 microcontroller.

Environment: via linuxulator (ubuntu/debian-env) the espressif-RTOS-sdk and the xtensa-lx106-toolchain is installed (tried to install from scratch natively before, but I failed). The hello_world-example in espressif's RTOS-SDK compiles with the linuxulator-installation from freebsd-userspace (IDF_PATH is set to /compat/ubuntu/<path-to-environment>) without errors.

When trying to upload to the contoller via

gmake flash

the system shows the following:

Toolchain version: esp-2020r3-49-gd5524c1
Compiler version: 8.4.0
Python requirements from /compat/ubuntu/home/userdir/.esp/ESP8266_RTOS_SDK/requirements.txt are satisfied.
App "hello-world" version: v3.4-112-gda7ce37b
Flashing binaries to serial port /dev/cuaU0 (app at offset 0x10000)...
esptool.py v2.4.0
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
gmake: *** [/compat/ubuntu/home/userdir/.esp/ESP8266_RTOS_SDK/components/esptool_py/Makefile.projbuild:76: flash] Error 2

When trying to get connection via

esptool.py --trace --port /dev/cuaU0 flash_id

I'm receiving:

esptool.py v4.10.0
Serial port /dev/cuaU0
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
    0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    55555555                          | UUUU
<repeated above output lots of times>
.

A fatal error occurred: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

Of cause I searched at the troubleshooting-docs of espressif, but I didn't find a proper solution. It's not a hardware/wiring problem as under linux it runs with the esp8266-SDK/xtensa-gcc above (plus same cable and wiring).

When trying using the freebsd native py311-esptool, it fails with the same error.

Somebody may have a useful hint where to look further?

Best regards and
thank you for reading
Paule

 

[AlfredoLlaquet]

WARNING 1: Seeing that you have received no additional responses in more than 72 hours, with nothing but good intentions in my heart, especially helping you, I outsourced your case to a non-subject expert-in-training and below the horizontal line is what it had to say.

WARNING 2: Use it all only as an inspiration or starting investigative point and check everything using official sources. That it sounds certain doesn't mean it is; these non-subjects are trained to first and foremost sound certain.

WARNING 3: Read in full before doing anything. Then, decide what you want to do.

Note: If you end up solving your problem, please write a post explaining what fixed it, so it gets documented for the community.

---

Symptom
esptool is repeatedly sending the sync pattern and receiving zero bytes back (“No serial data received”). That usually means one of:

• Wrong device node
• Serial RX path not delivering data to userland
• ESP8266 never enters the ROM bootloader (often due to RTS/DTR/flow-control behavior)

1) Confirm USB-serial attach, driver, and device nodes

# dmesg -a | tail -n 200
# ls -l /dev/cuaU* /dev/ttyU*

2) Ensure nothing else has the port open

# fstat /dev/cuaU0
# fstat /dev/ttyU0

HAZARD: Stopping processes can interrupt services or sessions. Verify the PID/program before terminating anything.

3) Apply known-good serial defaults on the .init device
This reduces “surprise” line behaviors when a program opens the port and disables common flow-control pitfalls.

# stty -f /dev/cuaU0.init -crtscts -ixon -ixoff -rtsdtr -hupcl clocal cs8 -parenb -cstopb
# stty -a -f /dev/cuaU0

Notes

• -crtscts disables RTS/CTS hardware flow control.
• -ixon -ixoff disables XON/XOFF software flow control.
• -rtsdtr changes the default “assert RTS/DTR on open” behavior; it does not prevent an application from explicitly toggling RTS/DTR later.

4) Remove auto-reset/auto-boot from the equation (manual bootloader entry)
Manually force the ESP8266 into ROM bootloader mode (typical: hold GPIO0 low while resetting), then run esptool with resets disabled:

$ esptool.py --port /dev/cuaU0 --baud 115200 --before no-reset --after no-reset flash_id

If flash_id is not accepted by the installed esptool, verify the subcommand spelling:

$ esptool.py --help

Interpretation

• Works with --before no-reset: serial RX/TX is fine; failure is in auto-reset/boot-mode selection (RTS/DTR semantics, flow control, or reset circuitry).
• Still fails: treat as a port/driver/data-path issue.

5) Verify raw UART output from the ESP8266 on reset (RX path check)
The ESP8266 ROM prints a boot log at 74880 baud right after reset. Use pyserial miniterm and press reset:

$ python3 -m serial.tools.miniterm /dev/cuaU0 74880

Expected: a short boot message (e.g., “ets … boot mode …”).
No output indicates either (a) reset is not occurring under the test conditions, or (b) RX is not reaching userland (wrong node, wiring/level issue, or a USB-serial driver/control-line quirk).

6) If only auto-reset fails, keep it disabled for flashing
When manual bootloader entry + --before no-reset works, keep using that mode so esptool does not toggle RTS/DTR. For SDK Makefile flows, pass through equivalent options (skip reset before/after), or invoke esptool.py directly with --before no-reset --after no-reset.

7) Adapter/chipset-specific behavior
Some USB-serial adapters behave differently on FreeBSD vs Linux, especially around RTS/DTR and flow control. If the “no-reset” path succeeds but auto-reset never does, test with a different adapter family (FTDI or CP210x are commonly robust) to isolate a driver/control-line interaction.