Debug Hang using ARM Launch Pad 2015.Q4 and KDS 3.0.0

[razed11]

Per Erich Styger's instructions I downloaded the latest ARM GCC tools from Launch Pad and created a symbolic link from /Applications/KDS_3.0.0/Contents/toolchain to them. This is on OS X El Capitan.

I also upgraded to the latest JLink tools and linked its JLink directory to <KDS_HOME>/segger.

Under these conditions I can use .../toolchain/bin/arm-none-eabi-gdb to connect to .../segger/JLinkGDBServer when both are launched from the command line. I can load my test ELF file and step through its simple loop.

From KDS this process hangs. It just says "configuring GDB aborting configuring GDB".

I exited KDS and had to kill the KDS process from the command line. I launched KDS again and specified a path for the GDB server log file. The output showed that it correctly attaches to the target (FRDM 64 board) and was listening on the expected TCP/IP ports. I tried to connect using arm-none-eabi-gdb but this timed out.

I also tried the other way round: I launched GDB server from the command line and told KDS not to launch GDB server. When I ran the debugger it got 99 or 100% and hung as usual but I did not see any connection in the server's output.

Everything works just fine with the original install. Any ideas?

Thanks,

Kenny

[BlackNight]

Hi Kenny,

I'm using sucessfully the lauchpad 5.2 2015q4 toolchain with KDS v3.0.0, but under Windows, and I have not seen any issues.

Have you tried the same with the 4.9 2015q3 toolchain, and does it work for you? The 4.9 2015q3 re-added Python support, so maybe this is causing issues for you?

Erich

[razed11]

I haven't. I'll give a try this week sometime. Do you mean python support for gdb? Maybe this is related. I use Python quite a bit and perhaps my Anaconda install of Python 3.x is messing with things. Although I was able so use 2015.Q4 gdb with the latest JLinkGDBServer. Still, I'll give it a try. I read somewhere that this same behavior can occur with Eclipse CDT when some dynamic library isn't found. Perhaps it's looking for Python 2.

Related to this: Do you know why the Segger tools have a "CL" version of of JLinkGDBServer? Both JLinkGDBServer and JLinkGDBServerCL exist in the default KDS installation but the CL version is not included with the Segger download.

[BlackNight]

Yes, ARM has added Python support to GDB, but this is in a separate gdb executable. But maybe it has a connection. The Segger CL version is the 'Command Line' one which is used as GDB. And both files are included in my download from Segger (but I'm using Windows, if this is making a difference)?

Erich

[razed11]

Hi Erich,

I found this issue Eclipse/CDT issue with GDB 7.10. Basically due to a bug, 7.10 is comparing as less than 7.2 and several features are disabled.

https://www.sourceware.org/ml/gdb/2015-09/msg00000.html

I'm stumped as to how your version can be working. Apparently the bug was fixed, as he mentions, in Mars CDT 8.8 but KDS is at Luna. Of course you've been known to customize things :smileyhappy:

I pointed the toolchain to 2015.Q3 which uses GDB 7.9 (where the string compare would not fail) and it worked. At least this indicates that gdb-py is not an issue.