ESP32 An existing connection was forcibly closed

Sysprogs forums Forums VisualGDB ESP32 An existing connection was forcibly closed

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #23065
    nevyn
    Participant

    I’m trying to deploy code to an ESP32 board we have put together and we have made the connections as per the tutorial and installed JTAG headers.

    JTAG debugger: Olimex ARM-USB0OCD-H
    Error message:

    VisualGDB version: 5.4.10.2594
    ------------------ System.IO.IOException ------------------
    System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

    Testing VisualGDB connection:

    Open On-Chip Debugger 0.9.0 (2018-10-12)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    adapter speed: 3000 kHz
    Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
    esp32 interrupt mask on
    VisualGDB_OpenOCD_Ready
    Info : clock speed 3000 kHz
    Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
    Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    cpu0: Current bits set: BreakIn BreakOut RunStallIn
    cpu1: Current bits set: none
    Info : esp32: Debug controller was reset (pwrstat=0xE5, after clear 0x5F).
    Info : accepting 'gdb' connection on tcp/50610
    Info : Target halted. PRO_CPU: PC=0x00000000 (active) APP_CPU: PC=0x00000000
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
    Info : esp32: Core was reset (pwrstat=0xFF, after clear 0xFF).
    Info : Target halted. PRO_CPU: PC=0x00000000 (active) APP_CPU: PC=0x00000000
    Info : Flash mapping 0: 0x3ffc0590 -> 0x3ffc0590, 1048321 KB
    Info : Flash mapping 1: 0x3ffc0590 -> 0x3ffc0590, 1048321 KB
    Info : Flash mapping 2: 0xac5308 -> 0xa35cf054, 10559 KB

    I have tried several debuggers and the response varies from Visual Studio becoming unresponsive to errors such as the above.

    I have double checked the connections between the JTAG debugger and the board and that looks good.  I have also double checked the schematic with the tutorial and that looks good as well.

    I have also tried searching and I’m not getting anything really that is helping.

    Any thoughts on what I can try?

    Regards
    Mark

    #23068
    support
    Keymaster

    Hi,

    As OpenOCD doesn’t mention an incoming gdb connection, it looks like something (likely a firewall or antivirus) is blocking it. Please try disabling your firewall/antivirus software and try again. Please also consider starting a debug session and checking the logs from both gdb and OpenOCD (double-check that both are using the same TCP port). If the OpenOCD does show the “incoming gdb connection” message, please share the updated log and we will help you find the relevant message.

    #23069
    nevyn
    Participant

    PC has Windows Defender as the only firewall/AV and I have turned it off temporarily.

    Started a debug session and the GDB Session reports Remote communication error.  Target disconnected.: No error.

    OpenOCD log:

    C:\SysGCC\esp32\esp32-bsp\OpenOCD\bin\openocd.exe -c "gdb_port 50810" -c "telnet_port 50811" -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -c "adapter_khz 3000" -f target/esp32.cfg -c "echo VisualGDB_OpenOCD_Ready"
    Open On-Chip Debugger 0.9.0 (2018-10-12)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    adapter speed: 3000 kHz
    Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
    esp32 interrupt mask on
    VisualGDB_OpenOCD_Ready
    Info : clock speed 3000 kHz
    Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
    Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    cpu0: Current bits set: BreakIn BreakOut RunStallIn
    cpu1: Current bits set: none
    Info : esp32: Debug controller was reset (pwrstat=0xE5, after clear 0x5F).
    Info : Target halted. PRO_CPU: PC=0x00000000 (active) APP_CPU: PC=0x00000000
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : accepting 'gdb' connection on tcp/50810
    Info : esp32: Debug controller was reset (pwrstat=0xE5, after clear 0x5F).
    Info : Target halted. PRO_CPU: PC=0x40007BA1 (active) APP_CPU: PC=0x00000000
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Debug controller was reset (pwrstat=0xE5, after clear 0x5F).
    Info : esp32: Debug controller was reset (pwrstat=0xE5, after clear 0x5F).
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
    Info : esp32: Core was reset (pwrstat=0xFF, after clear 0xFF).
    Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
    Info : esp32: Debug controller was reset (pwrstat=0xFF, after clear 0xFF).
    Info : esp32: Core was reset (pwrstat=0xFF, after clear 0xFF).
    Info : Target halted. PRO_CPU: PC=0x00000000 (active) APP_CPU: PC=0x00000000
    Info : Flash mapping 0: 0x3ffc0590 -> 0x3ffc0590, 1048321 KB
    Info : Flash mapping 1: 0x3ffc0590 -> 0x3ffc0590, 1048321 KB
    Info : Flash mapping 2: 0xc35c38 -> 0x23f8a014, 10559 KB
    Info : Flash mapping 3: 0x1378fb8 -> 0x134de78, 19932 KB
    Info : Flash mapping 4: 0xa4fccc -> 0x4921f9, 19939 KB
    Info : Flash mapping 5: 0x17 -> 0x1482608, 4543 KB
    Info : Flash mapping 6: 0x13698c0 -> 0x23f8a044, 10559 KB
    Info : Flash mapping 7: 0xa4fcc8 -> 0x224, 6457 KB
    Info : Flash mapping 8: 0x1 -> 0x2b, 19767 KB

    plus more of the same.

    GDB Session Log:

    VisualGDB is licensed to Mark Stevens
    -gdb-version
    =thread-group-added,id="i1"
    ~"GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10\n"
    ~"Copyright (C) 2015 Free Software Foundation, Inc.\n"
    ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n"
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    ~"This GDB was configured as \"--host=i686-host_pc-mingw32 --target=xtensa-esp32-elf\".\nType \"show configuration\" for configuration details."
    This GDB was configured as "--host=i686-host_pc-mingw32 --target=xtensa-esp32-elf".
    Type "show configuration" for configuration details.
    ~"\nFor bug reporting instructions, please see:\n"
    ~"<http://www.gnu.org/software/gdb/bugs/>.\n"
    ~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n"
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    ~"For help, type \"help\".\n"
    ~"Type \"apropos word\" to search for commands related to \"word\"...\n"
    ~"Reading symbols from C:/GitHub/Meadow-ESP32/Source/MeadowComms/Debug/MeadowComms.elf..."
    ~"done.\n"
    ~"GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10\n"
    ~"Copyright (C) 2015 Free Software Foundation, Inc.\n"
    ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n"
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    ~"This GDB was configured as \"--host=i686-host_pc-mingw32 --target=xtensa-esp32-elf\".\nType \"show configuration\" for configuration details."
    This GDB was configured as "--host=i686-host_pc-mingw32 --target=xtensa-esp32-elf".
    Type "show configuration" for configuration details.
    ~"\nFor bug reporting instructions, please see:\n"
    ~"<http://www.gnu.org/software/gdb/bugs/>.\n"
    ~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n"
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    ~"For help, type \"help\".\n"
    ~"Type \"apropos word\" to search for commands related to \"word\".\n"
    ^done
    -list-features
    ^done,features=["frozen-varobjs","pending-breakpoints","thread-info","data-read-memory-bytes","breakpoint-notifications","ada-task-info","language-option","info-gdb-mi-command","undefined-command-error-code","exec-run-start-option"]
    -gdb-set disassembly-flavor intel
    ^error,msg="No symbol \"disassembly\" in current context."
    -gdb-set print demangle off
    ^done
    set remotetimeout 60
    &"set remotetimeout 60\n"
    =cmd-param-changed,param="remotetimeout",value="60"
    ^done
    target remote :50810
    &"target remote :50810\n"
    ~"Remote debugging using :50810\n"
    &"Remote communication error. Target disconnected.: No error.\n"
    ^error,msg="Remote communication error. Target disconnected.: No error."
    mon gdb_breakpoint_override hard
    &"mon gdb_breakpoint_override hard\n"
    &"\"monitor\" command not supported by this target.\n"
    ^error,msg="\"monitor\" command not supported by this target."
    mon reset halt
    &"mon reset halt\n"
    &"\"monitor\" command not supported by this target.\n"
    ^error,msg="\"monitor\" command not supported by this target."
    mon program_esp32 "C:/GitHub/Meadow-ESP32/Source/MeadowComms/Debug/bootloader/bootloader.bin" 0x1000
    &"mon program_esp32 \"C:/GitHub/Meadow-ESP32/Source/MeadowComms/Debug/bootloader/bootloader.bin\" 0x1000\n"
    &"\"monitor\" command not supported by this target.\n"
    ^error,msg="\"monitor\" command not supported by this target."
    -target-disconnect
    ^error,msg="You can't do that when your target is `exec'"
    -gdb-exit
    ^exit

    The first line has the telnet port and GDB port off by 1, is this correct?

    Regards,
    Mark

    • This reply was modified 5 years, 11 months ago by nevyn.
    #23071
    nevyn
    Participant

    Forgot to mention, the same project deployed to a WROVER-KIT has always worked with no issues when deployed from the same PC.

    Regards,
    Mark

    #23072
    support
    Keymaster

    Hi,

    Thanks for the update. It looks like OpenOCD does get an incoming connection from gdb, so the problem should not be caused by the firewall (OpenOCD likely ends the connection when it discovers some critical error without showing more details).

    If OpenOCD works with another board, we would advise comparing the schematics of the 2 boards and checking JTAG signals on both boards with an oscilloscope.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.