Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esptool remote access -p socket://w.x..y.x bridge not working (IDFGH-13268) #14200

Closed
3 tasks done
ammaree opened this issue Jul 16, 2024 · 12 comments
Closed
3 tasks done
Assignees
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally

Comments

@ammaree
Copy link

ammaree commented Jul 16, 2024

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

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

@espressif-bot espressif-bot added the Status: Opened Issue is new label Jul 16, 2024
@github-actions github-actions bot changed the title esptool remote access -p socket://w.x..y.x bridge not working esptool remote access -p socket://w.x..y.x bridge not working (IDFGH-13268) Jul 16, 2024
@radimkarnis
Copy link
Collaborator

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.

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Jul 26, 2024
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Cannot Reproduce Issue cannot be reproduced and removed Status: In Progress Work is in progress labels Jul 29, 2024
@ammaree
Copy link
Author

ammaree commented Aug 13, 2024

@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.

@igrr
Copy link
Member

igrr commented Aug 13, 2024

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.)

@ammaree
Copy link
Author

ammaree commented Aug 14, 2024

@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?

@dobairoland
Copy link
Collaborator

We did not see the backtrace previously and received no further communication. So we closed it. I'm reopening now.

@dobairoland dobairoland reopened this Aug 14, 2024
@espressif-bot espressif-bot added Status: Opened Issue is new and removed Status: Done Issue is done internally Resolution: Cannot Reproduce Issue cannot be reproduced labels Aug 14, 2024
@ammaree
Copy link
Author

ammaree commented Aug 14, 2024

@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.

@igrr
Copy link
Member

igrr commented Aug 14, 2024

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.

@ammaree
Copy link
Author

ammaree commented Aug 14, 2024

@igrr
Copy link
Member

igrr commented Aug 14, 2024

@ammaree
Copy link
Author

ammaree commented Aug 14, 2024

Have had an issue open there for 2 weeks with no response at all..

@espressif-bot espressif-bot added Status: Selected for Development Issue is selected for development Status: In Progress Work is in progress and removed Status: Opened Issue is new Status: Selected for Development Issue is selected for development labels Aug 26, 2024
@ammaree
Copy link
Author

ammaree commented Aug 27, 2024

@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 !

@radimkarnis
Copy link
Collaborator

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...

@espressif-bot espressif-bot added the Status: Reviewing Issue is being reviewed label Aug 28, 2024
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: In Progress Work is in progress Status: Reviewing Issue is being reviewed labels Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

5 participants