Closed ammaree closed 3 days ago
Hello @ammaree,
the Device PID identification is only supported on COM and /dev/ serial ports.
is only a note to the users - not an error.
This only applies to users who want to use the USB-Serial/JTAG mode of our more recent chips - then the PID must be detected for esptool to select a correct reset sequence.
For classic USB-to-UART usage, this has no effect. The desired operation (read_flash, write_flash, or erase_flash) should run normally.
@dobairoland @radimkarnis
Can we please reopen this issue, it is not resolved. Below is a copy of the error messages:
irmacs % esptool.py -b 115200 -p socket://192.168.0.8:2323 read_flash 0 all sp2pm_pre60071.hex 23:08:30
esptool.py v4.8.dev4
Serial port socket://192.168.0.8:2323
Connecting...
Device PID identification is only supported on COM and /dev/ serial ports.
Traceback (most recent call last):
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/bin/esptool.py", line 37, in <module>
esptool._main()
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 1170, in _main
main()
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 721, in main
esp = esp or get_default_connected_device(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 1049, in get_default_connected_device
_esp = detect_chip(
^^^^^^^^^^^^
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/cmds.py", line 99, in detect_chip
detect_port.connect(connect_mode, connect_attempts, detecting=True)
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/loader.py", line 703, in connect
last_error = self._connect_attempt(reset_strategy, mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/loader.py", line 588, in _connect_attempt
reset_strategy() # Reset the chip to bootloader (download mode)
^^^^^^^^^^^^^^^^
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/reset.py", line 38, in __call__
self.reset()
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/reset.py", line 101, in reset
self._setDTRandRTS(False, False)
File "/Users/andremaree/.espressif/python_env/idf5.4_py3.12_env/lib/python3.12/site-packages/esptool/reset.py", line 66, in _setDTRandRTS
"I", fcntl.ioctl(self.port.fileno(), TIOCMGET, struct.pack("I", 0))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 6] Device not configured
I am trying to connect to an ESP32 device through an ESP8266 running ESP-Link software. All the other functionality works through the ESP-Link device, just not flash read/write operations.
FWIW, printing a useful error message instead of an exception traceback when a socket://
port is used without disabling DTR/RTS reset would be nice. It also appears when using QEMU...
@ammaree it's not possible to put the device into download mode (toggle DTR/RTS) over a TCP socket. You need to either use RFC2217 or put the device into download mode manually and disable reset in esptool (--before-reset etc.)
@igrr
Thanks for the feedback. I now did some more homework, got the details of difference between socket vs telnet (with/without RFC2217). I am beginning to believe that the old/original ESP-Link software on the ESP8266 does not support RFC2217.
Closest newer alternative would be the ESP32-S3-USB-Bridge, am I correct?
The challenge I however see is that the https://github.com/espressif/esp-dev-kits/tree/master/esp32-s3-usb-bridge/examples/usb_wireless_bridge firmware only uses ESP-NOW and not normal IP. This implies it will only work in a local LAN context and not across the internet at a remote site?
Any specific reason why ESP-NOW is supported but not normal IP?
I have tried placing orders for the ESP-32-S3-USB-Bridge on 3 different AliExpress suppliers, all 3 accepted the order (for 6x items) and then came back saying not in stock. Anywhere else I can try to source these units?
We did not see the backtrace previously and received no further communication. So we closed it. I'm reopening now.
@dobairoland
Thanks, but if you can provide some information on the questions above, much appreciated.
Access to a simple, reliable mechanism to access devices at remote locations to diagnose and fix crashed situation is the MOST PRESSING need we see.
A simple device such as the ESP32-S3-USB-Bridge (preferably in a case) with UART to USB Bridge and Telnet (with RFC2217) to enable remote read/modify/write flash access is CRITICAL.
If the firmware can be configured to also function with JTAG and/or SWD support, even if just in a LAN context, a great bonus.
AFAIK, ESP32-S3-USB-Bridge is not mass-produced (https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32s3/esp32-s3-usb-bridge/user_guide.html#sample-request). However you can use any ESP32-S3 development board for the same purpose, there is nothing hardware-specific to this task.
That said, I am not aware of existing software for ESP32-S3 which does exactly what you are looking for. We had an internal branch with RFC2217 support for https://github.com/espressif/esp-usb-bridge, but I think it was never released. There was also work done by @DNedic on a similar application in Rust (https://github.com/esp-rs/rfc2217-rs), however it's not something that you can use out of the box yet.
What about https://github.com/espressif/esp-dev-kits/tree/master/esp32-s3-usb-bridge/examples/usb_wireless_bridge it seems to be doing serial flashing, which means controlling IO0 and EN remotely in some way?
As far the ESP32-S3-USB-Bridge is concerned, only reason I am trying to get those is the nice form and pinouts, currently trying to do with S3 Mini https://www.aliexpress.com/item/1005005449219195.html?spm=a2g0o.productlist.main.1.564b6e3fhZBc99&algo_pvid=1e19d30d-77c1-4ebc-bf1a-75ad87bb4135&algo_exp_id=1e19d30d-77c1-4ebc-bf1a-75ad87bb4135-0&pdp_npi=4%40dis%21ZAR%2190.90%2136.36%21%21%215.00%212.00%21%402103868a17236221521404789e0de3%2112000033123977233%21sea%21ZA%210%21ABX&curPageLogUid=lg5f4lS2H9Sa&utparam-url=scene%3Asearch%7Cquery_from%3A but not a nice solution to deploy to remote locations.
If you have a question about https://github.com/espressif/esp-dev-kits/tree/master/esp32-s3-usb-bridge/examples/usb_wireless_bridge, please open an issue in https://github.com/espressif/esp-dev-kits/.
Have had an issue open there for 2 weeks with no response at all..
@igrr
Very encouraged to see the change in "Status" becoming "Selected for Development " and "In Progress", just not sure what this relates to.
If it relates to the ESP32_S3_USB_BRIDGE and firmware to support remote devices, wonderful !!!!
I have still not received any response to the issue raised in https://github.com/espressif/esp-dev-kits/ and we are a month later.
I have been able to source 3x ESP32_USB_BRIDGE devices and 3x MuseLab ESPLink devices (almost equivalent but with ESP32-S2). Now I just need firmware that works over IP to access a remote device.
Please !
Hi @ammaree,
the recent status change applies to the DTR/RTS transitions being applied when a TCP socket:
port is used:
printing a useful error message instead of an exception traceback when a socket:// port is used without disabling DTR/RTS reset would be nice. It also appears when using QEMU...
Answers checklist.
General issue report
We are trying to use an ESP-01 with esp-link v3.2.47-g9c6530d to access remote devices. The telnet to UART functionality on ports 23 and 2323 works correctly. We can reset the device remotely using the HTTP interface "uC Console" option. Device log output is displayed on the HTTP uConsole window as well as via the UART
The problem comes in when we try to do read_flash, write_flash or erase_flash operations, esptool consistently returns...
Device PID identification is only supported on COM and /dev/ serial ports.
Any suggestions to fix this?
If not fixable, ANY suggestions for an affordable device that can be deployed remotely that will enable us to access and troubleshoot remote devices via an existing Wifi installation at the remote site?
Thanks