Date: Sat, 27 Apr 2024 11:28:55 +0200 From: FreeBSD User <freebsd@walstatt-de.de> To: Tomek CEDRO <tomek@cedro.info> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>, "Tom Jones" <thj@freebsd.org> Subject: Re: serial/ulscom: response timeout using pySerial/esptool.py Message-ID: <20240427112922.7acdd6ea@thor.intern.walstatt.dynvpn.de> In-Reply-To: <CAFYkXjmnLypK4LdR-3raBes8_4f2snGjN3nHCUZmty0=HSy3cQ@mail.gmail.com> References: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> <CAFYkXjmnLypK4LdR-3raBes8_4f2snGjN3nHCUZmty0=HSy3cQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Thu, 25 Apr 2024 21:51:21 +0200
Tomek CEDRO <tomek@cedro.info> schrieb:
> CP2102 are pretty good ones and never let me down :-)
>=20
> Is your UART connection to ESP32 working correctly? Can you see the
> boot message and whatever happens next in terminal (cu / minicom)? Are
> RX TX pins not swapped? Power supply okay?
The ESP32 used are=20
- ESP32-WROOM32 D1 mini, have 10 pieces of those, on each single one same b=
ehaviour on same
host
- ESP32-WROOM32 sold by Chinese distributor AZdelivery in Germany, I got a =
bunch of them,
Revision 1 (baught 2020) and a more recent revision V4, baught a couple of =
months ago.
AGAIN: ALL chips do not communicate with my private hosts (dmesg: CPU micro=
code: updated from
0x1f to 0x21 CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.18-MHz K8-c=
lass CPU)), OS:
FreeBSD 15.0-CURRENT #39 main-n269723-4ba444de708b: Sat Apr 27 06:42:44 CES=
T 2024 amd64,
mainboard is a crappy Z77 Pro4 ASrock,=20
pciconf excerpts:
[...]
ichsmb0@pci0:0:31:3: class=3D0x0c0500 rev=3D0x04 hdr=3D0x00 vendor=3D0x8=
086 device=3D0x1e22
subvendor=3D0x1849 subdevice=3D0x1e22 vendor =3D 'Intel Corporation'
device =3D '7 Series/C216 Chipset Family SMBus Controller'
class =3D serial bus
subclass =3D SMBus
bar [10] =3D type Memory, range 64, base 0xf7c15000, size 256, enabled
bar [20] =3D type I/O Port, range 32, base 0xf040, size 32, enabled
...
ehci1@pci0:0:29:0: class=3D0x0c0320 rev=3D0x04 hdr=3D0x00 vendor=3D0x8=
086 device=3D0x1e26
subvendor=3D0x1849 subdevice=3D0x1e26 vendor =3D 'Intel Corporation'
device =3D '7 Series/C216 Chipset Family USB Enhanced Host Controll=
er'
class =3D serial bus
subclass =3D USB
bar [10] =3D type Memory, range 32, base 0xf7c17000, size 1024, enabl=
ed
cap 01[50] =3D powerspec 2 supports D0 D3 current D0
cap 0a[58] =3D EHCI Debug Port at offset 0xa0 in map 0x14
cap 13[98] =3D PCI Advanced Features: FLR TP
...
xhci0@pci0:0:20:0: class=3D0x0c0330 rev=3D0x04 hdr=3D0x00 vendor=3D0x8=
086 device=3D0x1e31
subvendor=3D0x1849 subdevice=3D0x1e31 vendor =3D 'Intel Corporation'
device =3D '7 Series/C210 Series Chipset Family USB xHCI Host Contr=
oller'
class =3D serial bus
subclass =3D USB
bar [10] =3D type Memory, range 64, base 0xf7c00000, size 65536, enab=
led
cap 01[70] =3D powerspec 2 supports D0 D3 current D0
cap 05[80] =3D MSI supports 8 messages, 64 bit enabled with 1 message
>=20
> Are boards generic devkits of custom hardware? ESP32 in addition to RX
> TX needs two control lines Reset and Boot that will switch the chip to
> bootloader / flashing mode. Most USB-to-UART use RTS/CTS lines for
> that. Are you sure these lines are available on your board and
> connected to the target correctly? Do you have Reset and Boot buttons
> on the board so you could trigger bootloader by hand (hold Boot, press
> and release Reset, device will be in bootloader upload mode, retry
> esptool flashing now). You can also play with the buttons with active
> terminal attached (i.e. minicom) to see if they work as expected.
I tried minivom, but I have to confess, I'm a "noice" in that matter, so do=
not expect
professional debugging infos:
Unsuccessful issueing the following command on three different types of ESP=
32 as
described above, I use at least two of them and even one (a D1 mini) just u=
nfolded from
its sealed anti static bag) while observing the minicom attached via -D /de=
v/cuaU1:
[...]
[ohartmann]: esptool.py --chip esp32 --baud 115200 --connect-attempts 400 -=
-port /dev/cuaU1
read_mac esptool.py v4.7.0
Loaded custom configuration from /pool/home/ohartmann/esptool.cfg
Serial port /dev/cuaU1
Connecting...
A serial exception error occurred: device reports readiness to read but ret=
urned no data
(device disconnected or multiple access on port?) Note: This error originat=
es from pySerial.
It is likely not a problem with esptool, but with the hardware connection o=
r drivers. For
troubleshooting steps visit:
https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
[...]
On the reference minicom terminal I observed with the D1 mini (minicom -b 1=
15200 -D
/dev/cuaU1):
[...]
Welcome to minicom 2.8
OPTIONS: I18n=20
Compiled on Apr 27 2024, 09:04:50.
Port /dev/cuaU1, 10:50:53
Press CTRL-A Z for help on special keys
ts Jul 29 2019 12:21:46
rst:x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=
=BD U
[... the older ESP32 from 2020 ...]
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
=EF=BF=BDun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
es Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH]=EF=BF=BD(=EF=BF=BD:=EF=
=BF=BD=EF=BF=BD=EF=BF=BD =EF=BF=BD
[... and the one purchased last year, called revision V4 ...]
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_=EF=BF=BD=EF=BF=BD\RXL c=EF=BF=BDR=D5=B9=EF=BF=BD=
8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DOUT, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
=EF=BF=BDAa
Which seems judged from the issued date the same chip.
And again, for the recoed: I tried every USB port (USB 2 as well as USB 3, =
I use a USB 3 hub
as well with external power, but that doesn't matter).
Also, the same happens with a Lenovo T560 notebook, either with esptool.py =
4.5 and 4.7.0.
At work I have a Fujitsu Celsius 750 running FreeBSD 14-STABLE (no access n=
ow, must wait until
Monday). And again for the record: ANY of the chips tested now and failing =
work like a charme
with ANY cabling and no matter whether USB 2 oder USB 3 port used on that F=
ujitsu box.
When I got the ESP32 D1 mini and none of the first ordered delivery worked,=
I wanted to make
sure the chips are defective by checking them on the work's box and was sur=
prised that they
worked no matter how often I tried the esptool command shown above, no matt=
er what cabling and
no matter whether I compiled the ulscom driver into the kernel or let the d=
evd attach the
proper driver.
But we also have a bunch of Fujitsu Esprimo Q5XX clients. A couple of them =
run FreeBSD
14-STABLE with a GENERIC kernel. Same problem, no chip does work on them!
The ESP32 D1 mini has CP2104 UART!
>=20
> Minicom serial terminal is pretty cool as it allows you to watch UART
> behavior on adapter (un)plug. In minicom you can also enable/disable
> hardware flow control lines (Ctrl+A O -> Serial Port Setup -> (F)
> Hardware Flow Control). You can switch that easily and watch the
> target behavior. If this is the problem you may want to use stty (1)
> to enable/disable hardware flow control on the port.
[...]
[ohartmann]: stty -g -f /dev/cuaU1
gfmt1:cflag=3D8b00:iflag=3D5:lflag=3D0:oflag=3D0:discard=3Df:dsusp=3D19:eof=
=3D4:eol=3Dff:eol2=3Dff:erase=3D7f:erase2=3D8:intr=3D3:kill=3D15:lnext=3D16=
:min=3D0:quit=3D1c:reprint=3D12:start=3D11:status=3D14:stop=3D13:susp=3D1a:=
time=3D3:werase=3D17:ispeed=3D9600:ospeed=3D9600
Issuing=20
stty -f /dev/cuaU1 speed 115200
multiple times flip flops serial speed between 9600 and 115200 (?).
[... after hitting frustrated the reapting arrow key up in the terminal, ex=
ecuting the
esptool.py command several times in a row, I get this ...]
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=
=BD U=EF=BF=BDets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5564
load:0x40078000,len:0
load:0x40078000,len:13756
entry 0x40078fb4
I (29) boot: ESP-IDF v3.0.3 2nd stage bootloader
I (29) boot: compile time 08:53:32
I (30) boot: Enabling RNG early entropy source...
I (34) boot: SPI Speed : 40MHz
I (38) boot: SPI Mode : DIO
I (42) boot: SPI Flash Size : 4MB
I (46) boot: Partition Table:
I (49) boot: ## Label Usage Type ST Ofset Len=EF=BF=
=BDets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=BD U=EF=BF=
=BD U=EF=BF=BDets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DONLOAD_BOOT(UART0/UART1/SDIO_REI_RE_ts J=
ul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
ts Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DONLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
U=EF=BF=BD U=EF=BF=BD=EF=BF=BDets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2=
))
waiting for download
>=20
> Can you try with another board? ESP32 has fuses that may permanently
> disable and/or mess up some hardware features.
A reported above, I tried several boards of the same series and I used thre=
e different
revisions of the same ESP32-WROOM32 chip. The ESP32 D1 mini doe have defini=
tely another
revision number of the chips used (newer, but I can report this when I have=
access to the
Fujitsu WS).
>=20
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
I'm out of ideas here.
As I insinuated in my report, I suspect the ASrock crap mainboard to be the=
culprit part, but
I tried a bunch of Lenovo T460, T560 and T450 which are at hand as well as =
a couple of Fujitsu
desktop PCs Esprimo Q5xx with the very same results. To my own surprising, =
my Fujitsu Celsius
75X workstation on my desk NEVER showed any issue with FreeBSD 14-STABLE (I=
compile the OS
almost every day, so expect here a moving target).
To summarize up: either I make a serious and capital mistake in an area of =
configuration
and/or kernel configuration which clouds the investigation or there is a se=
rious problem with
the serial bus system on 14 and CURRENT.
I also have a "maker style" I2C hub which attaches also via CP2101 UART to =
USB. I never got
this thingi to work with the notebooks or my private boxe so I considered i=
t broken. Since we
are to monitor some environmental parameters I ordered a new one and return=
in the "broken"
one. testing the considered broken one with the Fujitsu Celsius WS revealed=
that the broken
one is working very well.
So, at this point I will close my "adventure report".
Next time I will provide the OS revisions, chipset details and the pciconf =
-lcvbc output of
any host used.
Thanks in advance and kind regards
Oliver=20
--=20
O. Hartmann
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240427112922.7acdd6ea>