Re: serial/ulscom: response timeout using pySerial/esptool.py
- In reply to: FreeBSD User : "Re: serial/ulscom: response timeout using pySerial/esptool.py"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 27 Apr 2024 10:49:06 UTC
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 from an official FreeBSD site for FBSD 13.2-RELEASE, gives me on an ESP32 D1 mini, not working with the afore mentioned host, gives this (after a loop of 100x issued the esptool.py 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 Scheme 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 Scheme 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 Scheme 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 minor 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: > > > CP2102 are pretty good ones and never let me down :-) > > > > 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 > - 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 of months ago. > > AGAIN: ALL chips do not communicate with my private hosts (dmesg: CPU microcode: 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 CEST 2024 amd64, > mainboard is a crappy Z77 Pro4 ASrock, > > pciconf excerpts: > [...] > ichsmb0@pci0:0:31:3: class=0x0c0500 rev=0x04 hdr=0x00 vendor=0x8086 device=0x1e22 > subvendor=0x1849 subdevice=0x1e22 vendor = 'Intel Corporation' > device = '7 Series/C216 Chipset Family SMBus Controller' > class = serial bus > subclass = SMBus > bar [10] = type Memory, range 64, base 0xf7c15000, size 256, enabled > bar [20] = type I/O Port, range 32, base 0xf040, size 32, enabled > .. > ehci1@pci0:0:29:0: class=0x0c0320 rev=0x04 hdr=0x00 vendor=0x8086 device=0x1e26 > subvendor=0x1849 subdevice=0x1e26 vendor = 'Intel Corporation' > device = '7 Series/C216 Chipset Family USB Enhanced Host Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xf7c17000, size 1024, enabled > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] = PCI Advanced Features: FLR TP > .. > xhci0@pci0:0:20:0: class=0x0c0330 rev=0x04 hdr=0x00 vendor=0x8086 device=0x1e31 > subvendor=0x1849 subdevice=0x1e31 vendor = 'Intel Corporation' > device = '7 Series/C210 Series Chipset Family USB xHCI Host Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 64, base 0xf7c00000, size 65536, enabled > cap 01[70] = powerspec 2 supports D0 D3 current D0 > cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message > > > > > > > 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 ESP32 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: > > [...] > [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 returned no data > (device disconnected or multiple access on port?) Note: This error originates 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 > > [...] > > On the reference minicom terminal I observed with the D1 mini (minicom -b 115200 -D > /dev/cuaU1): > [...] > > Welcome to minicom 2.8 > > OPTIONS: I18n > 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� U� U� U� U� U� U� 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 > �un 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]�(�:��� � > > > [... 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_��\RXL c�Rչ� 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 > �Aa > > > 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 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. > > 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 surprised that they > worked no matter how often I tried the esptool command shown above, no matter 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 them run FreeBSD > 14-STABLE with a GENERIC kernel. Same problem, no chip does work on them! > > The ESP32 D1 mini has CP2104 UART! > > > > 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=8b00:iflag=5:lflag=0:oflag=0:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:erase2=8:intr=3:kill=15:lnext=16:min=0:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=3:werase=17:ispeed=9600:ospeed=9600 > > Issuing > > 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, executing 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� U� U� U� U� U� U� U�ets 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�ets Jul 29 2019 12:21:46 > > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) > waiting for download > U� U� U� U� U� U� U� U�ets Jul 29 2019 12:21:46 > > rst:0x1 (POWERON_RESET),boot:0x3 (DONLOAD_BOOT(UART0/UART1/SDIO_REI_RE_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 (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� U��ets Jul 29 2019 12:21:46 > > rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) > waiting for download > > > > > > 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 three different > revisions of the same ESP32-WROOM32 chip. The ESP32 D1 mini doe have definitely another > revision number of the chips used (newer, but I can report this when I have access to the > Fujitsu WS). > > > > > -- > > 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 serious 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 it 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 > > -- O. Hartmann