[ABANDONED] Random errors with remote debugging using ARM JLinkGDBServer

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

  • [ABANDONED] Random errors with remote debugging using ARM JLinkGDBServer

    Hi!

    I'm trying to set up a raspberry pi to enable debugging over IP for an NXP FRDM k64 dev board, but I've run into an intermittent issue. I posted about it on the NXP forums to see if the source may have been the IDE's debug client, but they suggested that the issue likely stemmed from the GDB server. So I'm asking here to see if anyone has any insight (since the ARM version of JLkinkGDBServer is officially unsupported)

    I'm using MCUXpresso 10.3.1 and Kinetis Design Studio 3.2.0, both Eclipse based IDEs.
    The raspberry pi is connected to the k64 via USB and is running JLinkGDBServer with the following parameters
    sudo ./JLinkGDBServer -device MK64FN1M0xxx12 -endian little -if SWD -speed 4000 -select USB -noir -noLocalhostOnly -log ./jlink.log -nohalt -vd

    Local debugging works perfectly with the board plugged in directly to my PC. On the Pi, JLinkGDBServer runs without error. However, when attempting to use to the Pi as a remote debugger, debugging will sometimes work, but often (on seemingly random occasions) it will error out and close the debug session before it finishes starting up.
    The error shown is always the following:
    Error in final launch sequence
    Failed to execute MI command:
    -target-select remote 172.16.22.225:2331
    Error message from debugger back end:
    Unknown remote qXfer reply: OK
    Unknown remote qXfer reply: OK


    I investigated this but have been unable to find any substantial information. The only reference to the error that I've found online is this forum post, but it's a different scenario, and I've been unable to get the proposed fix to work. I've found documentation that indicates that the error may be associated with a timeout being hit, but I found that increasing remote timeout did not reduce occurrences of the error. At this point, it looks to me like the issue is either within JLinkGDBServer itself or is simply due to the parameters I'm launching it with.

    After recording some logs from the server, I found no obvious errors, but there is a slight difference in the sequence of events when the client connects. All successful runs share the same pattern, and likewise for all unsuccessful runs.

    The relevant section of the logs is shown below (timestamps removed). Before this section, all of the logs are effectively identical.
    Success
    Failure
    Connected to 172.16.120.208
    +$qSupported:multiprocess+;qRelocInsn+#2a
    +
    $PacketSize=4000;qXfer:memory-map:read-;QStartNoAckMode+;hwbreak+;qXfer:features:read+#b1
    +
    $QStartNoAckMode#b0
    +
    $OK#9a
    +$Hg0#df
    $OK#9a
    $qXfer:features:read:target.xml:0,fff#7d
    $m<?xml version="1.0"?>
    Connected to 172.16.120.208
    +$qSupported:multiprocess+;qRelocInsn+#2a
    +
    $PacketSize=4000;qXfer:memory-map:read-;QStartNoAckMode+;hwbreak+;qXfer:features:read+#b1
    +$QStartNoAckMode#b0
    +
    $OK#9a
    $QStartNoAckMode#b0
    $OK#9a
    +$Hg0#df$qXfer:features:read:target.xml:0,fff#7d
    $OK#9a
    $m<?xml version="1.0"?>




    For more complete context, two complete logs are attached. One successful and one unsuccessful run.*
    • Note that for the failed attempt, remotetimeout was set to 10 seconds in the launch configuration for the GDB client. This increased the delay before the error was thrown but did not have any other notable effect.
    • Further note that I'm inclined to dismiss JLINK_GetHWStatus(...) as the culprit, since there are failure cases in which it does not appear at all during the erroneous section of the log.


    If anyone has seen this inconsistent behavior or has advice for how to prevent/troubleshoot it, I'd love to hear your input!
    Files
    • fail-jlink.log

      (14.52 kB, downloaded 512 times, last: )
    • success-jlink.log

      (18.97 kB, downloaded 494 times, last: )