Am Thu, 25 Apr 2024 21:51:21 +0200
Tomek CEDRO <to...@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
