[ABANDONED] newer gdb (GNU ARM) client drops connection immediately after connecting to remote / Segger GDB Server

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] newer gdb (GNU ARM) client drops connection immediately after connecting to remote / Segger GDB Server

    Got a problem with new'er GDB clients from GNU ARM toolchain dropping connection immediately after connecting to the Segger GDB Server.
    The last trace from GDB is 'cannot access memory .. ' which I thought, I would resolve by 'set mem inaccessible by default off' before the connect attempt, but this does not help.

    Working / without this behaviour GDB client : GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417-git
    With this behaviour / one not working for me : GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git, GNU gdb (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.2.1.20190227-git

    Server started with : JLinkGDBServerCLExe -if jtag -device MCIMX7D7_A7_0 -endian little -speed auto -port 2331 -swoport 2332 -telnetport 2333 -noir -localhostonly 1 -strict -timeout 0 -nogui

    GDB trace from "good" / working session for me - file "working_gdb_inside_trace.txt"

    From non working / bad session for me , which is identical between two "bad" versions mentioned above: "non_working_gdb_inside_trace.txt"


    The connection is closed immediately after the cannot access memory thus Segger exists. As mentioned, i do specifically set "set mem inaccessible-by-default off" in call cases.
    The last piece of trace from Segger GDB server log is:

    Source Code

    1. 02-00000000-00-00024577-00C6: T83FFF700 024:573 JLINK_ReadMem (0x18E59FC0, 0x0040 Bytes, ...) -- CPU_ReadMem(64 bytes @ 0x18E59FC0) - Data: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA ... returns 0x01 (0004ms, 0761ms total)
    2. 03-00000000-00-00024577-0034: WARNING: Failed to read memory @ address 0x18E59FC0
    3. 01-0000000C-00-00024577-0007: $E01#a6
    4. 00-0000000C-00-00024578-000F: $m18e59fe8,4#0c
    5. 02-00000000-00-00024580-009D: T83FFF700 024:578 JLINK_ReadMem (0x18E59FE8, 0x0004 Bytes, ...) -- CPU_ReadMem(4 bytes @ 0x18E59FE8) - Data: AA AA AA AA returns 0x01 (0002ms, 0763ms total)
    6. 03-00000000-00-00024580-0034: WARNING: Failed to read memory @ address 0x18E59FE8
    7. 01-0000000C-00-00024580-0007: $E01#a6
    8. 03-00000000-00-00024580-001D: GDB closed TCP/IP connection
    9. 03-00000000-00-00024787-0038: Restoring target state and closing J-Link connection...
    10. 02-00000000-00-00024787-0045: T962B5700 024:787 JLINK_IsOpen() returns 0x01 (0000ms, 0763ms total)
    11. 02-00000000-00-00024787-005C: T962B5700 024:787 JLINK_ExecCommand("ClrAllBPs", ...). returns 0x00 (0000ms, 0763ms total)
    12. 03-00000000-00-00024818-0011: Shutting down...
    Display All


    GDB Server logs attached too, "seggergdbsvr_ok.log" one is from working version, "serggergdbsvr_con_dropped.log" from bad.

    Any help with this .. ?
    Files

    The post was edited 1 time, last by v01d ().

  • Still an issue.

    A guy from Linaro group, when I shared same logs as here, suggested in a chat that the server (J-Link's GDBServer) sends corrupt response.
    Could you check? (per logs included already)