Date: Sat, 27 Apr 2024 12:49:06 +0200 From: FreeBSD User <freebsd@walstatt-de.de> To: freebsd-current@freebsd.org Subject: Re: serial/ulscom: response timeout using pySerial/esptool.py Message-ID: <20240427124933.3e4d81e2@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20240427112922.7acdd6ea@thor.intern.walstatt.dynvpn.de> References: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> <CAFYkXjmnLypK4LdR-3raBes8_4f2snGjN3nHCUZmty0=HSy3cQ@mail.gmail.com> <20240427112922.7acdd6ea@thor.intern.walstatt.dynvpn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Sat, 27 Apr 2024 11:28:55 +0200 FreeBSD User <freebsd@walstatt-de.de> schrieb: Just for the record: running a small "victim NAS" based on an HP EliteDesk = 800 G2 mini, XigmaNAS (latest official version, kernel see below), installing packages f= rom an official FreeBSD site for FBSD 13.2-RELEASE, gives me on an ESP32 D1 mini, not worki= ng with the afore mentioned host, gives this (after a loop of 100x issued the esptool.p= y command, no issues detected): [...] nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac esptool.py v4.5 Serial port /dev/cuaU0 Connecting.......... Chip is ESP32-D0WD-V3 (revision v3.1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Sc= heme None Crystal is 40MHz MAC: XX:XX:XX:XX:XX:XX Uploading stub... Running stub... Stub running... MAC: XX:XX:XX:XX:XX:XX Hard resetting via RTS pin... [...] ... and those from AZdelivery (larger and older chips): [...] nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac esptool.py v4.5 Serial port /dev/cuaU0 Connecting......... Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Sc= heme None Crystal is 40MHz MAC: XX:XX:XX:XX:XX:XX Uploading stub... Running stub... Stub running... MAC: XX:XX:XX:XX:XX:XX Hard resetting via RTS pin... [...] or [... considered a different revision, but in fact the same old ESP32 as it = reveals itself as ...] nas01: ~# esptool.py --chip esp32 --port /dev/cuaU0 --baud 115200 read_mac esptool.py v4.5 Serial port /dev/cuaU0 Connecting........... Chip is ESP32-D0WDQ6 (revision v1.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Sc= heme None Crystal is 40MHz MAC: XX:XX:XX:XX:XX:XX Uploading stub... Running stub... Stub running... MAC: XX:XX:XX:XX:XX:XX Hard resetting via RTS pin... Big question is: is this an issue introduced with FBSD 14? In 2020 I played= around with my first attempts using the Arduino IDE which worked pretty well, with some mi= nor issues (I had to perform several attempts to get connected, using 12- and 13-STABLE that = time). But the Arduino IDE doen't work as well > Am Thu, 25 Apr 2024 21:51:21 +0200 > Tomek CEDRO <tomek@cedro.info> schrieb: >=20 > > 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? =20 >=20 > The ESP32 used are=20 > - ESP32-WROOM32 D1 mini, have 10 pieces of those, on each single one same= behaviour 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 o= f months ago. >=20 > AGAIN: ALL chips do not communicate with my private hosts (dmesg: CPU mic= rocode: updated from > 0x1f to 0x21 CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.18-MHz K8= -class CPU)), OS: > FreeBSD 15.0-CURRENT #39 main-n269723-4ba444de708b: Sat Apr 27 06:42:44 C= EST 2024 amd64, > mainboard is a crappy Z77 Pro4 ASrock,=20 >=20 > pciconf excerpts: > [...] > ichsmb0@pci0:0:31:3: class=3D0x0c0500 rev=3D0x04 hdr=3D0x00 vendor=3D0= x8086 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, enab= led > 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=3D0= x8086 device=3D0x1e26 > subvendor=3D0x1849 subdevice=3D0x1e26 vendor =3D 'Intel Corporation' > device =3D '7 Series/C216 Chipset Family USB Enhanced Host Contro= ller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 32, base 0xf7c17000, size 1024, ena= bled > 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=3D0= x8086 device=3D0x1e31 > subvendor=3D0x1849 subdevice=3D0x1e31 vendor =3D 'Intel Corporation' > device =3D '7 Series/C210 Series Chipset Family USB xHCI Host Con= troller' > class =3D serial bus > subclass =3D USB > bar [10] =3D type Memory, range 64, base 0xf7c00000, size 65536, en= abled > 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 >=20 >=20 > >=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. =20 >=20 > I tried minivom, but I have to confess, I'm a "noice" in that matter, so = do not expect > professional debugging infos: >=20 > Unsuccessful issueing the following command on three different types of E= SP32 as > described above, I use at least two of them and even one (a D1 mini) just= unfolded from > its sealed anti static bag) while observing the minicom attached via -D /= dev/cuaU1: >=20 > [...] > [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... >=20 > A serial exception error occurred: device reports readiness to read but r= eturned no data > (device disconnected or multiple access on port?) Note: This error origin= ates from pySerial. > It is likely not a problem with esptool, but with the hardware connection= or drivers. For > troubleshooting steps visit: > https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html >=20 > [...] >=20 > On the reference minicom terminal I observed with the D1 mini (minicom -b= 115200 -D > /dev/cuaU1): > [...] >=20 > Welcome to minicom 2.8 >=20 > OPTIONS: I18n=20 > Compiled on Apr 27 2024, 09:04:50. > Port /dev/cuaU1, 10:50:53 >=20 > Press CTRL-A Z for help on special keys >=20 > ts Jul 29 2019 12:21:46 >=20 > rst:x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V= 2)) > 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 >=20 >=20 > [... the older ESP32 from 2020 ...] >=20 > 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 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_= V2)) > waiting for download > es Jun 8 2016 00:22:57 >=20 > 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 >=20 >=20 > [... and the one purchased last year, called revision V4 ...] >=20 > 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 >=20 > 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 >=20 >=20 > Which seems judged from the issued date the same chip. >=20 >=20 > 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). >=20 > Also, the same happens with a Lenovo T560 notebook, either with esptool.p= y 4.5 and 4.7.0. >=20 > At work I have a Fujitsu Celsius 750 running FreeBSD 14-STABLE (no access= now, 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 Fujitsu box. >=20 > When I got the ESP32 D1 mini and none of the first ordered delivery worke= d, I wanted to make > sure the chips are defective by checking them on the work's box and was s= urprised that they > worked no matter how often I tried the esptool command shown above, no ma= tter what cabling > and no matter whether I compiled the ulscom driver into the kernel or let= the devd attach the > proper driver. > But we also have a bunch of Fujitsu Esprimo Q5XX clients. A couple of the= m run FreeBSD > 14-STABLE with a GENERIC kernel. Same problem, no chip does work on them! >=20 > 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. =20 >=20 > [...] > [ohartmann]: stty -g -f /dev/cuaU1 > gfmt1:cflag=3D8b00:iflag=3D5:lflag=3D0:oflag=3D0:discard=3Df:dsusp=3D19:e= of=3D4:eol=3Dff:eol2=3Dff:erase=3D7f:erase2=3D8:intr=3D3:kill=3D15:lnext=3D= 16:min=3D0:quit=3D1c:reprint=3D12:start=3D11:status=3D14:stop=3D13:susp=3D1= a:time=3D3:werase=3D17:ispeed=3D9600:ospeed=3D9600 >=20 > Issuing=20 >=20 > stty -f /dev/cuaU1 speed 115200 >=20 > multiple times flip flops serial speed between 9600 and 115200 (?). >=20 > [... after hitting frustrated the reapting arrow key up in the terminal, = executing the > esptool.py command several times in a row, I get this ...] >=20 > 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 >=20 > 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 >=20 > 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 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DONLOAD_BOOT(UART0/UART1/SDIO_REI_RE_ts= Jul 29 2019 > 12:21:46 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_= V2)) > waiting for download > ets Jul 29 2019 12:21:46 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_= V2)) > waiting for download > ts Jul 29 2019 12:21:46 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_= V2)) > waiting for download > ets Jul 29 2019 12:21:46 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DONLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V= 2)) > waiting for download > U=EF=BF=BD U=EF=BF=BD=EF=BF=BDets Jul 29 2019 12:21:46 >=20 > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_= V2)) > waiting for download >=20 >=20 > >=20 > > Can you try with another board? ESP32 has fuses that may permanently > > disable and/or mess up some hardware features. =20 >=20 > A reported above, I tried several boards of the same series and I used th= ree different > revisions of the same ESP32-WROOM32 chip. The ESP32 D1 mini doe have defi= nitely another > revision number of the chips used (newer, but I can report this when I ha= ve access to the > Fujitsu WS). >=20 > >=20 > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info =20 >=20 >=20 > I'm out of ideas here. >=20 > As I insinuated in my report, I suspect the ASrock crap mainboard to be t= he culprit part, but > I tried a bunch of Lenovo T460, T560 and T450 which are at hand as well a= s a couple of > Fujitsu desktop PCs Esprimo Q5xx with the very same results. To my own su= rprising, my > Fujitsu Celsius 75X workstation on my desk NEVER showed any issue with Fr= eeBSD 14-STABLE (I > compile the OS almost every day, so expect here a moving target). >=20 > To summarize up: either I make a serious and capital mistake in an area o= f configuration > and/or kernel configuration which clouds the investigation or there is a = serious problem with > the serial bus system on 14 and CURRENT. >=20 > I also have a "maker style" I2C hub which attaches also via CP2101 UART t= o USB. I never got > this thingi to work with the notebooks or my private boxe so I considered= it broken. Since we > are to monitor some environmental parameters I ordered a new one and retu= rn in the "broken" > one. testing the considered broken one with the Fujitsu Celsius WS reveal= ed that the broken > one is working very well. >=20 > So, at this point I will close my "adventure report". >=20 > Next time I will provide the OS revisions, chipset details and the pcicon= f -lcvbc output of > any host used. >=20 > Thanks in advance and kind regards >=20 > Oliver=20 >=20 >=20 --=20 O. Hartmann
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240427124933.3e4d81e2>