Kinetis Design Studio debugging KDS project on MK60FN1M0VMD12 with J-Link Failed to execute -exec-ru

[MCU_Larry]

I need help troubleshooting a debugging issue with using the J-Link Ultra+ emulator/probe.  I have created a KDS project within the Kinetis Design Studio redirecting output from the console component to a UART. I have compiled it and selected the Debug Configurations -> GDB SEGGER J-Link Debugging configuration. It appears the values are filled in correctly with the device name being MK60FN1M0XXX12. When I launch the debugger I receive the error in final launch sequence "Failed to execute MI command: -exec-run" Error message from debugger back end.  If I use the ozone debugger (SEGGER's debugger for the J-Link probe), I can flash and run the elf file fine.  I would like not to use the separate Ozone debugger and concatenate my development activities to a single IDE for this MCU.

[ErichStyger]

Can you share a screenshot of your settings?

It should look similar to this one which uses the K22FN512:

Your message indicates that it is not able to launch the GDB server. The default config uses

${jlink_path}/${jlink_gdbserver}

so check the following:

and check if the path and file exists.

I hope this helps,

Erich

[MCU_Larry]

This is my console output:

SEGGER J-Link GDB Server V5.10n - Terminal output channel
Connection closed by the GDB server.

-larry

[MCU_Larry]

SEGGER J-Link GDB Server V7.70 - Terminal output channel

Connection closed by the GDB server.

I updated and still get this error.  

Thanks for the suggestions.  This is a simple bare metal project as I was trying to use the KDS for the first time to redirect the console to a UART on my MCU.  This should be a simple setup for using the J-Link.  Again the elf file runs and I can debug it using the SEGGER Ozone debugger. I will keep digging.

-larry

[ErichStyger]

I don't think this is your primary issue, but your J-Link version is very old. The current on is around v7.66.

I recommend that you update the J-Link installation in any case.

[MCU_Larry]

I don't have the SEGGER J-Link selection under Windows > Preferences > Run/Debug.  I did add the build variables to the Preferences > C/C++ > Build > Build Variables as you have them defined here.

-larry

[ErichStyger]

I still think you have your executable of the J-Link GDB server somehow wrong.

Maybe instead using variables in the launch config, point directly to the executable.

Your console view should look similar to this:

[ErichStyger]

You get that console view if you select it from the drop-down:

[MCU_Larry · Accepted solution]

Erich,

  I found my debug issue.  I have added to my Windows > Preferences > C/C++ > Build > Global Tools Paths and more recent toolchain in particular GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.07) 10.2.90.20210621-git\n in place of the KDS Default toolchain which is version GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs\n

I am experimenting to see if I could move away from an existing project using VSCode and Ozone to build and debug and use an NXP replacement IDE (KDS) to do my builds and debugging from one place for the MK60FN1M0VMD12 MCU. I am also going to have to configure another UART for the system and it is easier using the component library rather than digging through the MCU reference manual and data sheet to find the registers I need to set up. The software I am working with is using a CMake build system and I wanted to remove these restrictions so I can also add a unit test framework. The code is being built with this newer toolchain so I wanted to make sure it works with a simple UART Processor Expert project before I moved forward.  It did not occur to me that the GDB version could be the source of the issue. To reiterate I could debug the elf that the project built using the ozone debugger but not with this version of GDB using KDS.  Now I need to figure out why this version of GDB would be causing my issue.

-larry

[ErichStyger]

You always need to use a matching gdb for the binary you have built. So compiler and the debugger needs to be compatible. Using vastly different compiler version with a different gdb is going to be problematic in any case. So you should not mix-and-match them. It might be ok using a gdb v9 with a gcc v9, but still there might be subtle differences, so not recommended.

[MCU_Larry]

Here is my gdb traces view:

807,780 1-gdb-version
807,782 ~"GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.07) 10.2.90.20210621-git\n"
807,782 ~"Copyright (C) 2021 Free Software Foundation, Inc.\n"
807,783 ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is fre\
e software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitt\
ed by law."
807,783 ~"\nType \"show copying\" and \"show warranty\" for details.\n"
807,783 ~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".\n"
807,783 ~"Type \"show configuration\" for configuration details.\n"
807,783 ~"For bug reporting instructions, please see:\n"
807,783 ~"<https://www.gnu.org/software/gdb/bugs/>.\n"
807,783 ~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/\
software/gdb/documentation/>."
807,783 ~"\n\n"
807,783 ~"For help, type \"help\".\n"
807,783 ~"Type \"apropos word\" to search for commands related to \"word\".\n"
807,784 1^done
807,784 (gdb)
807,784 2-environment-cd C:/work/KDSWorkspacePrintf/Larry_Printf
807,797 2^done
807,797 (gdb)
807,798 3-gdb-set breakpoint pending on
807,813 3^done
807,813 (gdb)
807,813 4-gdb-set print object on
807,829 4^done
807,829 (gdb)
807,829 5-gdb-set print sevenbit-strings on
807,845 5^done
807,845 (gdb)
807,845 6-gdb-set charset ISO-8859-1
807,846 6^done
807,846 (gdb)
807,846 7source .gdbinit
807,861 &"source .gdbinit\n"
807,863 &".gdbinit: No such file or directory.\n"
807,863 7^error,msg=".gdbinit: No such file or directory."
807,863 (gdb)
807,863 8-gdb-set auto-solib-add on
807,877 8^done
807,877 (gdb)
807,878 9-file-exec-and-symbols C:/work/KDSWorkspacePrintf/Larry_Printf/Debug/Larry_Printf.elf
807,904 9^done
807,904 (gdb)
807,904 10-gdb-show language
807,923 10^done,value="auto"
807,923 (gdb)
807,923 11-gdb-set language c
807,939 11^done
807,939 (gdb)
807,939 12-interpreter-exec console "p/x (char)-1"
807,955 ~"$1 = 0xff\n"
807,955 12^done
807,955 (gdb)
807,956 13-data-evaluate-expression "sizeof (void*)"
807,971 13^done,value="4"
807,971 (gdb)
807,972 14-gdb-set language auto
807,987 14^done
807,987 (gdb)
807,987 15-interpreter-exec console "show endian"
807,988 ~"The target endianness is set automatically (currently little endian).\n"
807,988 15^done
807,988 (gdb)
807,990 16-break-insert -t main.c:main
808,693 16^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x000004e0",func="ma\
in",file="../Sources/main.c",fullname="C:\\work\\KDSWorkspacePrintf\\Larry_Printf\\Sources\\main.c",\
line="49",thread-groups=["i1"],times="0",original-location="main.c:main"}
808,693 (gdb)
808,701 17-break-insert -t main
808,713 17^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x000004e0",func="ma\
in",file="../Sources/main.c",fullname="C:\\work\\KDSWorkspacePrintf\\Larry_Printf\\Sources\\main.c",\
line="49",thread-groups=["i1"],times="0",original-location="main"}
808,713 (gdb)
808,714 18-exec-run
808,728 18^error,msg="Don't know how to run. Try \"help target\"."
808,728 (gdb)
808,729 19-gdb-exit
808,744 19^exit

[ErichStyger]

the GDB traces are not much helpful in your case. What would be more interesting are the J-Link console outputs.

[MCU_Larry]

ErichStyger,

  Thank you for that tip. Here is my KDS console view of the JLinkGDBServerCL.  Things look good in this view.  However I still cannot connect to the GDB server.

 

[ErichStyger]

Yes, everything looks good, except it should connect like this:

>>Waiting for GDB connection...Connected to 127.0.0.1

Do you have maybe the connection blocked by some firewall or similar?

[MCU_Larry]

Erich,

That's a good question. However, I am connected to the J-Link Ultra + over USB. I take it the debug configuration tries and runs the J-Link GDB server locally on the windows machine and then tries to connect with GDB over TCP/IP? I added the JLinkGDBServerCL.exe and the kinetis-design-studio.exe to the firewall and the debug session behaves the same.  Is there another app I need to add to allow through the firewall for loopback access?

[MCU_Larry]

I have modified my Debug Configuration to point directly to C:\Program Files\SEGGER\JLink\JLinkGDBServerCL.exe. I am not sure how you generated the console view from the KDS. That may be my issue.

I ran the JLinkGDBServer.exe directly and am able to launch the GDB Server task.  Attached is my window from that run.

 

[ErichStyger]

your settings show JTAG. Are you sure you don't want to use SWD?

[MCU_Larry]

I am connected to the SOM with a JTAG 10 pin connector.  What is the SWD connector?

[ErichStyger]

It is the same connector. SWD is just a different protocol (and the default) and requires less pins. Kinetis usually use SWD, unless you mux and use the additional JTAG pins.

[KalaimaniArumugamdev]

Hi,

  Update your j-link firmware and check again. It's works in case.

[MCU_Larry]

I recently updated to the latest version available I believe.  I will check it however.