esp8266 flashing stopped working with kernel 5.11.0-37-generic (ch341)

[Florian Baumgartner]

the esp8266 development boards like wemos D1 mini have an integrated usb-uart converter which allows to flash/monitor/debug the esp8266 by usb cable and a tool called esptool on linux, which is either standalone (esptool package) or integrated into some IDE (platformio + visio)

dmesg output:
[ 46.614510] usbcore: registered new interface driver usbserial_generic
[ 46.614523] usbserial: USB Serial support registered for generic
[ 46.615912] usbcore: registered new interface driver ch341
[ 46.615925] usbserial: USB Serial support registered for ch341-uart
[ 46.615938] ch341 1-9:1.0: ch341-uart converter detected
[ 46.616332] usb 1-9: ch341-uart converter now attached to ttyUSB0

This convenient flashing method worked without issues up to kernel 5.11.0-36-generic and stopped working with 5.11.0-37-generic. The issue remains the same whether I use the esptool package or the version bundled with platformio,

>> esptool --chip esp8266 --port /dev/ttyUSB0 --baud 115200 write_flash 0x0000 firmware.bin
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header

The communication to the esp8266 still seems to work, but the flash process includes some additional DTR/RTS magic in the beginning to switch the esp into flash mode before transmitting the data. My impression is that this DTR/RTS process might be broken. I can flash an esp with an external UART (some dongle) and manually triggering the flash mode. I tried with several cables, esps, ...

Booting the older kernel (5.11.0-36-generic) solves the issue ... There seems to be an update to the ch341 from kernel -36 to -37, but it is beyond my knowledge whether there is any connection.

Description: Ubuntu 20.04.3 LTS
Release: 20.04

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.11.0-37-generic 5.11.0-37.41~20.04.2
ProcVersionSignature: Ubuntu 5.11.0-37.41~20.04.2-generic 5.11.22
Uname: Linux 5.11.0-37-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.20
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 6 14:59:58 2021
InstallationDate: Installed on 2020-08-29 (403 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
SourcePackage: linux-signed-hwe-5.11
UpgradeStatus: No upgrade log present (probably fresh install)

[Florian Baumgartner (bafl)]

some more information:
 - I was able to reproduce the problem on a different computer.
 - flashing an ESP32 Devel board which is based on the cp210x instead of the ch341 works.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Denis Bondar (denisbondar)]

I confirm the problem on my two computers with KDE Neon after upgrading the kernel to 5.11.0-37-generic.
There is no problem on kernel 5.11.0-36-generic.
I use a development board NodeMCU with CH340G

[Florian Baumgartner (bafl)]

adding the option "--before no_reset" seems to solve the issue with kernel 5.11.0-37

esptool --before no_reset --chip esp8266 --port /dev/ttyUSB0 --baud 115200 write_flash 0x0000 firmware.bin

Even if I do not understand the why, this solves the issue for me.

Correction: Sorry for the too optimistic update. This solves the issue not reliably. The behavior with the 5.11.0-37 seems to be unpredictable (at least for me).

[Emil Muratov (emil-muratov)]

Same issue under 5.4.0-89 kernel. Tested about 10 different boards, those ones based on ch340G does not work. Ones using ch340C or ch340K DOES work (mostly esp32 boards).

[Emil Muratov (emil-muratov)]

Found it - https://github.com/Koenkk/zigbee2mqtt/issues/8663