logo elektroda
logo elektroda
X
logo elektroda

The system sees the port, but esptool does not - in other words, a Schrödingerian USB port

jakubprazmowskibox 294 8
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • #1 21477500
    jakubprazmowskibox
    Level 3  
    Hello... I have a problem with flashing my ESP32-H2 via ESP-IDF. It was working, but stopped, and now it just gives me an error that.... can't see the USB port, while the whole system sees it without problem. It seems to me that the problem lies somewhere deep within.... So maybe one of you has some broader insight and would be willing to explain to me what is going on. Thank you very much and best regards. I wanted to make myself a dice to throw from 00 to 99 for an RPG. I look forward to hearing back from you. I will look here often.
    AI: Can you provide the exact error message that appears when trying to flash the ESP32-H2? .
    [100%] Built target app
    esptool.py --chip esp32h2 -p /dev/ttyUSB0 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 12m --flash_size detect 0x0 bootloader/bootloader.bin 0x10000 blink.bin 0x8000 partition_table/partition-table.bin
    esptool.py v4.8.1
    Serial port /dev/ttyUSB0
    Connecting......................................

    A fatal error occurred: Failed to connect to ESP32-H2: No serial data received.
    For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
    CMake Error at run_serial_tool.cmake:66 (message):

    /home/kuba/.espressif/python_env/idf5.2_py3.12_env/bin/python;;/home/kuba/esp/components/esptool_py/esptool/esptool.py;--chip;esp32h2
    failed.

    make[3]: *** [CMakeFiles/flash.dir/build.make:70: CMakeFiles/flash] Error 1
    make[2]: *** [CMakeFiles/Makefile2:1909: CMakeFiles/flash.dir/all] Error 2
    make[1]: *** [CMakeFiles/Makefile2:1916: CMakeFiles/flash.dir/rule] Error 2
    make: *** [Makefile:273: flash] Error 2
    make failed with exit code 2, output of the command is in the /home/kuba/esp/examples/get-started/blink/build/log/idf_py_stderr_output_22621 and /home/kuba/esp/examples/get-started/blink/build/log/idf_py_stdout_output_22621

    AI: What version of ESP-IDF are you using to flash your ESP32-H2? .
    The latest one! 5.2.5-dirty harry! And esptool.py v4.8.1. in Arduino shows the same error. That it does not see the usb port. Thank you for your help!
  • ADVERTISEMENT
  • #2 21477739
    khoam
    Level 42  
    Try running esptool with the additional option " --trace ":
    Code: Bash
    Log in, to see the code
    .
    https://docs.espressif.com/projects/esptool/e...ol.html#tracing-esptool-serial-communications

    I assume that as a user you are in the group dialout , or uucp and have access to /dev/ttyUSB0.
    That it is sometimes worth replacing the USB cable is rather obvious.

    What kind of module is it specifically with the ESP32-H2? This, in the first instance, should be asked by the so-called AI. The ESP-IDF version has nothing to do with this problem.
  • ADVERTISEMENT
  • #3 21479563
    jakubprazmowskibox
    Level 3  
    >>21477739 in dialout I am, uucp group on Fedora I do not see. Linux sees /dev/ttyUSB0.... but ESP doesn't connect, and it was connecting nicely a few times in the beginning.... and then suddenly stopped. God! Shit! Help! How long do I have to sit on this? 4 months? Is it even possible to connect to the ESP32 or is someone out there blocking it somehow? What? Thanks for the answers.

    Added after 34 [minutes]: .

    Okay I did the whole TRACE thing with esptool.py and it came up with something like this.... can someone explain to me what o is?

    root@fedora:~/esp/esp-idf/examples/get-started/blink/build# esptool.py --trace --chip esp32h2 --port /dev/ttyUSB0 write_flash 0x1000 blink.bin
    esptool.py v4.8.1
    Serial port /dev/ttyUSB0
    Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
        0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        55555555                          | UUUU
    TRACE +0.000 Write 46 bytes: 
        c000082400000000 0007071220555555 | ...$........ UUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
    TRACE +0.101 No serial data received.
    .TRACE +0.051 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
        0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        55555555                          | UUUU
    TRACE +0.000 Write 46 bytes: 
        c000082400000000 0007071220555555 | ...$........ UUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
    TRACE +0.101 No serial data received.
    .TRACE +0.051 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
        0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        55555555                          | UUUU
    TRACE +0.000 Write 46 bytes: 
        c000082400000000 0007071220555555 | ...$........ UUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
    TRACE +0.101 No serial data received.
    .TRACE +0.051 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
        0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        55555555                          | UUUU
    TRACE +0.000 Write 46 bytes: 
        c000082400000000 0007071220555555 | ...$........ UUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
    TRACE +0.101 No serial data received.
    .TRACE +0.051 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
        0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        55555555                          | UUUU
    TRACE +0.000 Write 46 bytes: 
        c000082400000000 0007071220555555 | ...$........ UUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
    TRACE +0.101 No serial data received.
    .TRACE +0.703 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
        0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
        5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
        55555555                          | UUUU
    


    ...And so on a few more times. So what do we do? Can you unlock it for me remotely somehow?
  • ADVERTISEMENT
  • #4 21479604
    khoam
    Level 42  
    jakubprazmowskibox wrote:
    Good I did the whole TRACE thing with esptool.py and it came out something like this.... can someone explain to me what the o is about?
    .
    Subsequent blocks of identical TRACE messages show that esptool is retrying the connection. It sends the same SYNC command multiple times and consistently receives no response from the ESP32-H2. The messages indicate that the esptool cannot establish a connection with the ESP32-H2 chip. Sends the initial sync command (operation code 0x08) multiple times, but receives no acknowledgement or response back from the chip via the /dev/ttyUSB0 port.

    Possible causes of this problem are:
    - Invalid baud rate. The baud rate used by esptool may not match the baud rate expected by the ESP32-H2 in its current state (e.g. after a reset). Although the command does not explicitly specify a speed, esptool has default values and may sample different speeds.
    - The chip is not in bootloader mode. In order for the esptool to communicate and write to flash memory, the ESP32 must be in bootloader mode. This is usually achieved by holding down a specific button (e.g. BOOT or GPIO0) while resetting the chip.
    - Hardware issues. There may be a problem with the USB cable, the serial adapter or the ESP32-H2 chip itself.

    Unfortunately I don't know of any magic spells that I can cast remotely. Start by making sure the ESP32-H2 is correctly entered into bootloader mode.
  • #5 21479626
    jakubprazmowskibox
    Level 3  
    >>21479604 Ok thanks. I see... What does it mean to hold GPIO0? And second question, meaning what... I should try to send my program to the ESP at different speeds? But after all, it can't connect to it at all, and it hasn't connected and there's a problem with something there.... so this is probably not about the speed of the serial port. Oh well. Thanks for your help. I find it very strange. I give my Session ID: 05c8d1e7201c459d027b98d0aa095f035cd501d263b906bb26cabf3978b16dd136 in case you need it! I will be happy to pay for the unblocking. I live in Krakow.
  • #6 21479633
    khoam
    Level 42  
    jakubprazmowskibox wrote:
    what does it mean to hold GPIO0?
    .
    Actually, I have "simplified" a bit. It is about shorting GPIO0 to ground.
  • #7 21480266
    jakubprazmowskibox
    Level 3  
    >>21479633 And what do you think would help? I had GPIO0 busy with the normal digital output. Okay... maybe I'll check again sometime. These whole microcontrollers are some kind of egg. I thought I was going to make a robot, and I made a pile. Probably someone is scrupulously making sure not everyone can play with it. How about you? Are you good at programming microcontrollers? Do you have any business? Are you an affiliated electronics engineer?
  • ADVERTISEMENT
  • #8 21480364
    rtvserwisant
    Level 24  
    Don't you have GPIO1 and GPIO3 outputs connected to some converter, e.g. rs232, I myself had a case that when these 2 outputs were connected to TTL converter I couldn't program ESP8266
  • #9 21481190
    jakubprazmowskibox
    Level 3  
    >>21480364 Eeeee.... I don't have one, they're all occupied. I tried to handle the ESP32-H2 dual 2-digit (7-element) display.... but it derailed the whole thing for me, and maybe that's even a good thing, because now I'm doing more interesting things and not getting knocked around by some dumb code. ;-)

Topic summary

The discussion addresses an issue with flashing an ESP32-H2 microcontroller using ESP-IDF and esptool.py, where the system recognizes the USB port (/dev/ttyUSB0) but esptool fails to connect to the device, repeatedly timing out during the sync process. The problem likely stems from the ESP32-H2 not entering bootloader mode, which requires holding or shorting GPIO0 to ground during reset. Other potential causes include incorrect baud rate settings or interference from connected peripherals on UART pins (e.g., GPIO1 and GPIO3 connected to TTL converters). The user confirmed membership in the dialout group and verified USB port visibility on Fedora Linux. Suggestions include using the --trace option in esptool.py for detailed communication logs, verifying bootloader mode entry by manipulating GPIO0, checking for conflicting UART connections, and trying different baud rates. The discussion highlights the importance of hardware boot mode control and serial line conditions for successful flashing of ESP32-H2 devices.
Summary generated by the language model.
ADVERTISEMENT