Random errors when debugging remotely

[twyatt]

Hi!

I'm trying to set up a raspberry pi to enable debugging over IP for a FRDM k64, but I've run into an issue in both KDS and MCUX. I haven't been able to find any resources that mention the specific issue I'm having, so I'm hoping someone here can shed some light on the situation.

I'm using MCUXpresso 10.3.1 and Kinetis Design Studio 3.2.0.

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

With the board plugged in directly to my PC, JLink debugging works perfectly. On the Pi, JLinkGDBServer runs without error. However, when attempting to connect to the Pi as a remote debugger, MCUXpresso and KDS will sometimes work, but often (on seemingly random occasions) error out and fail to initialize the debug session.

The error shown in both 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've investigated this but have been unable to determine the cause. The only reference to this that I've found online is this forum post, but the scenario is different (and the accepted solution does not seem to be applicable).

After recording some logs from the server, I found no obvious errors, but a slight difference in the sequence of events when the client connects. Interestingly, all successful runs share the same pattern, and likewise for all unsuccessful runs. The differences are shown in red.

Success (KDS)	Failure (KDS)
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"?>

Two complete logs are attached, for one successful and one unsuccessful run using KDS.

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 have dismissed JLINK_GetHWStatus(...) as the culprit, since there are failure cases in which it does not not run at all during the initial connection.

If anyone has seen this or has advice for how to avoid this inconsistent error behavior, I'd love to hear it! I can provide additional logs as well if that's helpful.

As a side note, when I initially tried to configure remote debugging on MCUX, I found that the debug config editor never updated the launch file's "org.eclipse.cdt.debug.gdbjtag.core.ipAddress" value, so I had to manually correct it. It kept trying to use localhost:2331, which failed since I disabled gdbserver locally. I don't know if I just missed a config parameter or if that's the intended behavior, but it held me up for a while.

Additionally: With certain specific settings enabled in MCUX (eg nonstop debug mode), the Unknown remote qXfer reply error is thrown 100% of the time.

[FelipeGarcia]

Hi Thomas,

Because of you are using the Segger firmware and an external hardware as debugger (Raspberry Pi), I'd say this seems to be an error on the JLink commands not in the MCUXpresso IDE or the MCU by itself.

I highly recommend you to contact Segger support to see if they have more information regarding this issue.

https://www.segger.com/support/technical-support/

Sorry for the inconvenience this may cause you.

Best regards,

Felipe