From nobody Sat Apr 27 09:28:55 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VRPSH5XDNz5JDfC for ; Sat, 27 Apr 2024 09:29:35 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VRPSG2bc0z4Kym; Sat, 27 Apr 2024 09:29:34 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=gI4iBjx6; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id D93C4240456; Sat, 27 Apr 2024 11:29:25 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 0C2A82404BC; Sat, 27 Apr 2024 11:29:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1714210164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2JmscX7fPzUuEEHD28jhndGjlJWBcckZzfIc42rxaMY=; b=gI4iBjx6I4a2Sc5iEe+2m8DOe494G2qCbCJ4oWWNwDUnd9QuLJMSfGEGM4UJB6dt/fNgs3 suurPspZrku76VnXcgiiIHrnPGqHysIIjPW+codV6HiThedP2o461GrvJH+U7Kho3mji2J ZnBNCuYLsWGanCCa8H1O/TOADlEDzfCzmI3Jt2JbLLFeYD6/+Pfcg3V2zegSv46rH50JZS qHzRqnqLrBATHEPuvp5hLCcYKniYKi7EK58k+SjPJB1PuTkjUW0ZYzeX6d5iOkke1W5zua tly1mbKSnmVTgOvSVJpO9m7RqerQVVPVxI14/BC95ms+1wGkW2Vv4Uq5EXjGuw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-055-047-139.78.55.pool.telefonica.de [78.55.47.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id B96F724028F; Sat, 27 Apr 2024 11:29:23 +0200 (CEST) Date: Sat, 27 Apr 2024 11:28:55 +0200 From: FreeBSD User To: Tomek CEDRO Cc: FreeBSD CURRENT , "Tom Jones" Subject: Re: serial/ulscom: response timeout using pySerial/esptool.py Message-ID: <20240427112922.7acdd6ea@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: 0f2895 X-Rspamd-UID: 8621ae X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; HAS_ORG_HEADER(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4VRPSG2bc0z4Kym Am Thu, 25 Apr 2024 21:51:21 +0200 Tomek CEDRO 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