Re: serial/ulscom: response timeout using pySerial/esptool.py
Am Sat, 27 Apr 2024 11:28:55 +0200 FreeBSD User 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 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 0xf7c0, 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
Re: serial/ulscom: response timeout using pySerial/esptool.py
Am Thu, 25 Apr 2024 21:51:21 +0200 Tomek CEDRO 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 0xf7c0, 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
Re: serial/ulscom: response timeout using pySerial/esptool.py
Can you isolate out the extraneous stuff and loop tx and rx on a CP2101 board and send bytes through? I did a bunch of development on an esp8266 board in the last few weeks and had no issues, but I’ve no idea if it were the same usb serial chip. I’ll have a dig around and see if I have something matching On Thu, Apr 25, 2024, at 20:17, FreeBSD User wrote: > Hello, > > Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: > Thu Apr 25 18:48:56 > CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at > hand). > > Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 > notebook, Fujitsu Esprimo Q5XX > (simple desktop, Pentium Gold) or an oldish Fujitsu Celsius 7XX > workstation, 6 core Haswell > XEON. > > Phenomenon: a couple of weeks now I try to connect to several Xtensa > ESP32 dev boards > (ESP32-WROOM32 with CP2101 or CP2104 UART) via comms/py-esptool > (doesn't matter whether it is > tho port's py39-esptool 4.5 or the latest py-esptool 4.7.0, doesn't > matter whether pkg package > or self compiled on CURRENT and 14-STABLE, on all hardware platforms > same result). > > Attaching the ESP devel module via Micro USB cable (several type, > differnt vendors tried ...) > show > > dmesg: > [...] > ugen0.4: at usbus0 > uslcom0 on uhub3 > uslcom0: rev 1.10/1.00, addr 4> > on usbus0 > [...] > > When trying to connect to the ESP32 via below shown command (--trace > not every time issued), I > get no connection: > > [ohartmann]: esptool.py --trace --chip esp32 --baud 115200 --port > /dev/cuaU1 flash_id > esptool.py v4.7.0 > Loaded custom configuration from /pool/home/ohartmann/esptool.cfg > Serial port /dev/cuaU1 > Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 > timeout=0.100 data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > TRACE +0.102 No serial data received. > TRACE +0.052 command op=0x08 data len=36 wait_response=1 timeout=0.100 > data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > TRACE +0.107 No serial data received. > TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 > data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > TRACE +0.107 No serial data received. > TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 > data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > > > 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 > [...] > > > Whatever baud rate issued, in most cases on all tested OS versions and > almost all hardware > platforms except the Fujistu Celsius 7XX (2015 model) I do not get any > connection! And it get > more weird: To avoid out-of-sync-software I recompiled everything via > "portmaster -df > comms/py-pyserial comms/py-esptool" and after that, everything was > fine, the connection was > made, I got results out of the chip. Seconds later same problems. > > I exchanged cablings, exchanged the ESP32 model and vendor. Invariants > are 14-STABLE, daily > compiled, CURRENT. daily compiled. On my private box (old Z77 based > IvyBridge ASRock crap), a > couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo > Q5XX boxes there is always > this weird error message, but in very rare cases I get connection. > > Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last > complied today noon). No > matter what ESP32, no
Re: serial/ulscom: response timeout using pySerial/esptool.py
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? 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. 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. Can you try with another board? ESP32 has fuses that may permanently disable and/or mess up some hardware features. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
