Sometimes, there are ugly bugs in tools, and without knowing about them, it is likely to spend hours and hours, and of course to be frustrated. Knowing about these issues does not remove the issue, but at least helps to cut time to deal with it. And here is one which was nagging on me for a while with the GNU GDB debugger in Eclipse…..
💡 I have used the Q4 2014 GNU ARM Embedded (launchpad) toolsuite/gdb (4.9-2014-q4-major), and I have found that with that gdb version the issue described is fixed. If you are using Kinetis Design Studio, see “Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio” how to upgrade the tool chain.
I was happily debugging my project, making some changes, and suddenly I cannot debug it any more. What happens is that I can download the binary with GDB, but it immediately terminates and disconnects:
After digging and doing some trial and errors, I have found what is causing this.
Initializing. Target has been RESET and is active. Disconnected from "127.0.0.1" via 127.0.0.1 Terminating Gracefully... Target Disconnected.
Usually, gdb reports something like this:
internal-error: decode_line_full: Assertion `state->canonical_names[i].suffix != NULL' failed.
The problem is with GDB trying to set a breakpoint set on piece of code which does not exist any more. For example I used to reference a function ‘TestFunction’ before, and had a breakpoint on it. Now if this function is not linked any more, and I still have a breakpoint, the above failure happens:
I’m thinking this is a generic GDB client problem, and not a problem of the P&E Multilink or Segger J-Link GDB server.
The GDB client does not provide any information:
monitor clrbp monitor reset monitor halt monitor regs flushreg monitor speed auto Register cache flushed. The target endianness is set automatically (currently little endian)
And the GDB traces does not give an indication of the problem neither:
734,080 2-environment-cd C:/Users/tastyger/Data/HSLU/Vorlesung/INTRO_HS2014/git/INTRO_HS2014/Project\ s/INTRO_FRDM 734,084 2^done 734,084 (gdb) 734,084 3-gdb-set breakpoint pending on 734,094 3^done 734,094 (gdb) 734,094 4-enable-pretty-printing 734,094 4^done 734,094 (gdb) 734,094 5-gdb-set python print-stack none 734,104 5^done 734,104 (gdb) 734,104 6-gdb-set print object on 734,104 6^done 734,104 (gdb) 734,104 7-gdb-set print sevenbit-strings on 734,114 7^done 734,114 (gdb) 734,114 8-gdb-set charset ISO-8859-1 734,124 8^done 734,124 (gdb) 734,124 9set mem inaccessible-by-default off 734,124 10source .gdbinit 734,124 &"set mem inaccessible-by-default off\n" 734,124 =cmd-param-changed,param="mem inaccessible-by-default",value="off" 734,124 9^done 734,124 (gdb) 734,124 &"source .gdbinit\n" 734,125 11-gdb-set auto-solib-add on 734,125 &".gdbinit: No such file or directory.\n" 734,125 10^error,msg=".gdbinit: No such file or directory." 734,125 (gdb) 734,125 11^done 734,125 (gdb) 734,125 12-target-select remote localhost:2331 734,192 13-list-thread-groups 734,644 =thread-group-started,id="i1",pid="42000" 734,644 =thread-created,id="1",group-id="i1" 734,645 14-list-thread-groups --available 734,647 *stopped,frame={addr="0x00000000",func="??",args=[]},thread-id="1",stopped-threads="all" 734,647 12^connected 734,647 (gdb) 734,647 &"\n" 734,647 ^done 734,647 (gdb) 734,648 13^done,groups=[{id="i1",type="process",pid="42000"}] 734,648 (gdb) 734,648 14^error,msg="Can not fetch data now." 734,648 (gdb) 734,648 15monitor speed 1000 monitor clrbp monitor reset monitor halt monitor regs flushreg monitor \ speed auto 734,658 &"monitor speed 1000\n" 734,658 @"Target interface speed set to 1000 kHz\r\n" 734,658 15^done 734,658 (gdb) 734,658 &"monitor clrbp\n" 734,659 ^done 734,659 (gdb) 734,659 &"monitor reset\n" 734,681 @"Resetting target\r\n" 734,681 ^done 734,681 (gdb) 734,681 &"monitor halt\n" 734,681 ^done 734,681 (gdb) 734,681 &"monitor regs\n" 734,681 @"R0 = 00000000, R1 = 20000F18, R2 = 20000168, R3 = 12345678\n" 734,681 @"R4 = 4761032D, R5 = 40020000, R6 = 0000FFFF, R7 = 00000000\n" 734,681 @"R8 = AFBF9D3F, R9 = EFBBFFFB, R10= DFBEFEFD, R11= 00002000\n" 734,681 @"R12= FF7FEBFD, R13= 20003000, MSP= 20003000, PSP= FF7FBFFC\n" 734,681 @"R14(LR) = 20000121, R15(PC) = 00000BDC\n" 734,681 @"XPSR 61000000, APSR 60000000, EPSR 01000000, IPSR 00000000\n" 734,681 @"CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00\r\n" 734,681 ^done 734,681 (gdb) 734,682 &"flushreg\n" 734,682 ~"Register cache flushed.\n" 734,682 ^done 734,682 (gdb) 734,682 &"monitor speed auto\n" 734,682 @"Select auto target interface speed (2000 kHz)\r\n" 734,682 ^done 734,682 (gdb) 734,715 16monitor flash breakpoints 1 monitor semihosting enable monitor semihosting IOClient 1 734,721 17-list-thread-groups i1 734,723 &"monitor flash breakpoints 1\n" 734,723 @"Flash breakpoints enabled\r\n" 734,723 16^done 734,723 (gdb) 734,723 &"monitor semihosting enable\n" 734,723 18symbol-file C:\\Users\\tastyger\\Data\\HSLU\\Vorlesung\\INTRO_HS2014\\git\\INTRO_HS2014\\P\ rojects\\INTRO_FRDM\\Debug\\INTRO_FRDM.elf 734,723 @"Semi-hosting enabled (VectorAddr = 0x08)\r\n" 734,723 19load C:\\Users\\tastyger\\Data\\HSLU\\Vorlesung\\INTRO_HS2014\\git\\INTRO_HS2014\\Projects\ \\INTRO_FRDM\\Debug\\INTRO_FRDM.elf 734,723 ^done 734,723 (gdb) 734,723 &"monitor semihosting IOClient 1\n" 734,723 @"Semihosting I/O set to TELNET Client\r\n" 734,724 ^done 734,724 (gdb) 734,725 17^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x00000bdc",func="\ ??",args=[]},state="stopped"}] 734,725 (gdb) 734,725 &"symbol-file C:\\\\Users\\\\tastyger\\\\Data\\\\HSLU\\\\Vorlesung\\\\INTRO_HS2014\\\\git\\\\ \INTRO_HS2014\\\\Projects\\\\INTRO_FRDM\\\\Debug\\\\INTRO_FRDM.elf\n" 734,726 ~"Reading symbols from C:\\Users\\tastyger\\Data\\HSLU\\Vorlesung\\INTRO_HS2014\\git\\INTRO_\ HS2014\\Projects\\INTRO_FRDM\\Debug\\INTRO_FRDM.elf..." 734,726 20-stack-info-depth --thread 1 11 734,729 ~"done.\n" 734,731 18^done 734,731 (gdb) 734,731 21-gdb-show --thread-group i1 language 734,731 &"load C:\\\\Users\\\\tastyger\\\\Data\\\\HSLU\\\\Vorlesung\\\\INTRO_HS2014\\\\git\\\\INTRO_\ HS2014\\\\Projects\\\\INTRO_FRDM\\\\Debug\\\\INTRO_FRDM.elf\n" 734,731 ~"Loading section .interrupts, size 0xc0 lma 0x0\n" 734,732 19+download,{section=".interrupts",section-size="192",total-size="377725"} 734,732 19+download,{section=".interrupts",section-sent="192",section-size="192",total-sent="192",to\ tal-size="377725"} 734,732 ~"Loading section .cfmprotect, size 0x10 lma 0x400\n" 734,732 19+download,{section=".cfmprotect",section-size="16",total-size="377725"} 734,732 ~"Loading section .text, size 0x1f38 lma 0x410\n" 734,733 19+download,{section=".text",section-size="7992",total-size="377725"} 734,733 ~"Loading section .init_array, size 0x4 lma 0x2348\n" 734,733 19+download,{section=".init_array",section-size="4",total-size="377725"} 734,733 ~"Loading section .fini_array, size 0x4 lma 0x234c\n" 734,733 19+download,{section=".fini_array",section-size="4",total-size="377725"} 734,733 ~"Loading section .romp, size 0x18 lma 0x2350\n" 734,734 19+download,{section=".romp",section-size="24",total-size="377725"} 734,734 ~"Start address 0xbdc, load size 8232\n" 734,734 ~"Transfer rate: 2679 KB/sec, 1372 bytes/write.\n" 734,734 19^done 734,734 (gdb) 734,735 20^done,depth="1" 734,735 (gdb) 734,735 21^done,value="auto" 734,735 (gdb) 734,735 22-gdb-set --thread-group i1 language c 734,745 22^done 734,745 (gdb) 734,745 23-data-evaluate-expression --thread-group i1 "sizeof (void*)" 734,755 23^done,value="4" 734,755 (gdb) 734,759 24-gdb-set --thread-group i1 language auto 734,765 24^done 734,765 (gdb) 734,765 25-interpreter-exec --thread-group i1 console "show endian" 734,775 ~"The target endianness is set automatically (currently little endian)\n" 734,775 25^done 734,775 (gdb) 734,779 26-break-insert --thread-group i1 -t -f C:\\Users\\tastyger\\Data\\HSLU\\Vorlesung\\INTRO_HS\ 2014\\git\\INTRO_HS2014\\Projects\\INTRO_FRDM\\Sources\\main.c:main 734,779 27-break-insert --thread-group i1 -f C:\\Users\\tastyger\\Data\\HSLU\\Vorlesung\\INTRO_HS201\ 4\\git\\INTRO_HS2014\\Projects\\INTRO_Common\\Application.c:27 734,796 26^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000096c",func="ma\ in",file="../Sources/main.c",fullname="C:\\Users\\tastyger\\Data\\HSLU\\Vorlesung\\INTRO_HS2014\\git\ \\INTRO_HS2014\\Projects\\INTRO_FRDM\\Sources\\main.c",line="84",thread-groups=["i1"],times="0",orig\ inal-location="C:\\\\Users\\\\tastyger\\\\Data\\\\HSLU\\\\Vorlesung\\\\INTRO_HS2014\\\\git\\\\INTRO_\ HS2014\\\\Projects\\\\INTRO_FRDM\\\\Sources\\\\main.c:main"} 734,797 (gdb)
The P&E Server reports:
P&E GDB Server, Version 5.07.00.00 Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved Loading library C:\Freescale\KDS_1.1.1\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.1.4.201409071615\win32\gdi\unit_ngs_arm_internal.dll ... Done. Command line arguments: -device=KL25Z128M4 -startserver -serverport=7224 -interface=OPENSDA -speed=5000 -port=USB1 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MASS_ERASE=0 Device selected is kl25z128m4 User Specified Hardware Selection : Interface=OPENSDA and Port=USB1 Connecting to target. OpenSDA detected - Flash Version 1.14 Device is KL25Z128M4. Mode is In-Circuit Debug. 'Kinetis' is a registered trademark of Freescale. (C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com) API version is 101 Server running on 127.0.0.1:7224 Connection from "127.0.0.1" via 127.0.0.1 Copyright 2012 P&E Microcomputer Systems,Inc. Command Line :C:\Freescale\KDS_1.1.1\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.1.4.201409071615\win32\pegdbserver_console -device=KL25Z128M4 -startserver -serverport=7224 -interface=OPENSDA -speed=5000 -port=USB1 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MAS CMD>RE Initializing. Target has been RESET and is active. CMD>CM C:\Freescale\KDS_1.1.1\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.1.4.201409071615\win32\gdi\P&E\kl25z128m4_pflash_pipeline.arp Initializing. Initialized. ;version 1.03, 07/17/2013, Copyright P&E Microcomputer Systems, www.pemicro.com [mk_128k_n_pflash_m0] ;device freescale, kl25z128m4, 1x32x32k, desc=pflash_pipeline ;begin_cs device=$00000000, length=$00020000, ram=$20000000 Loading programming algorithm ... Done. CMD>EM Erasing. Module has been erased. Initializing. Initialized. ;version 1.03, 07/17/2013, Copyright P&E Microcomputer Systems, www.pemicro.com [mk_128k_n_pflash_m0] ;device freescale, kl25z128m4, 1x32x32k, desc=pflash_pipeline ;begin_cs device=$00000000, length=$00020000, ram=$20000000 Loading programming algorithm ... Done. CMD>PM Programming. Processing Object File Data ... . Programmed. CMD>VC Verifying object file CRC-16 to device ranges ... block 00000000-000000BF ... Ok. block 00000400-00002367 ... Ok. Checksum Verification Successful. (Cumulative CRC-16=$D438) CMD>RE Initializing. Target has been RESET and is active. Disconnected from "127.0.0.1" via 127.0.0.1 Terminating Gracefully... Target Disconnected.
The Segger J-Link server reports:
SEGGER J-Link GDB Server V4.88a Command Line Version JLinkARM.dll V4.88a (DLL compiled Jul 17 2014 18:20:19) -----GDB Server start settings----- GDBInit file: none GDB Server Listening port: 2331 SWO raw output listening port: 2332 Terminal I/O port: 2333 Accept remote connection: localhost only Generate logfile: off Verify download: on Init regs on start: on Silent mode: off Single run mode: on Target connection timeout: 5 sec. ------J-Link related settings------ J-Link Host interface: USB J-Link script: none J-Link settings file: none ------Target related settings------ Target device: MKL25Z128xxx4 Target interface: SWD Target interface speed: 1000kHz Target endian: little Connecting to J-Link... J-Link is connected. Firmware: J-Link V9 compiled Jul 17 2014 12:01:11 Hardware: V9.00 S/N: 609100567 Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB Checking target voltage... Target voltage: 2.94 V Listening on TCP/IP port 2331 Connecting to target...Connected to target Waiting for GDB connection...Connected to 127.0.0.1 Reading all registers Read 4 bytes @ address 0x00000000 (Data = 0x20003000) Target interface speed set to 1000 kHz Resetting target Halting target CPU... ...Target halted (PC = 0x00000BDC) R0 = 00000000, R1 = 20000F18, R2 = 20000168, R3 = 12345678 R4 = 4761032D, R5 = 40020000, R6 = 0000FFFF, R7 = 00000000 R8 = AFBF9D3F, R9 = EFBBFFFB, R10= DFBEFEFD, R11= 00002000 R12= FF7FEBFD, R13= 20003000, MSP= 20003000, PSP= FF7FBFFC R14(LR) = 20000121, R15(PC) = 00000BDC XPSR 61000000, APSR 60000000, EPSR 01000000, IPSR 00000000 CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 Reading all registers Select auto target interface speed (2000 kHz) Flash breakpoints enabled Semi-hosting enabled (VectorAddr = 0x08) Semihosting I/O set to TELNET Client Read 4 bytes @ address 0x00000BDC (Data = 0xB082B580) Downloading 192 bytes @ address 0x00000000 - Verified OK Downloading 16 bytes @ address 0x00000400 - Verified OK Downloading 7992 bytes @ address 0x00000410 - Verified OK Downloading 4 bytes @ address 0x00002348 - Verified OK Downloading 4 bytes @ address 0x0000234C - Verified OK Downloading 24 bytes @ address 0x00002350 - Verified OK Read 4 bytes @ address 0x00000BDC (Data = 0xB082B580) Read 2 bytes @ address 0x0000096C (Data = 0xF000) Read 2 bytes @ address 0x0000096C (Data = 0xF000) Read 2 bytes @ address 0x00000000 (Data = 0x3000) Read 2 bytes @ address 0x00000002 (Data = 0x2000) Read 2 bytes @ address 0x00000004 (Data = 0x0BDD) Read 2 bytes @ address 0x00000006 (Data = 0x0000) Read 2 bytes @ address 0x00000008 (Data = 0x0F49) Read 2 bytes @ address 0x0000000A (Data = 0x0000) Read 2 bytes @ address 0x0000000C (Data = 0x1769) Read 2 bytes @ address 0x0000000E (Data = 0x0000) Read 2 bytes @ address 0x00000010 (Data = 0x0F55) Read 2 bytes @ address 0x00000012 (Data = 0x0000) Read 2 bytes @ address 0x00000014 (Data = 0x0F55) Read 2 bytes @ address 0x00000016 (Data = 0x0000) Read 2 bytes @ address 0x00000018 (Data = 0x0F55) Read 2 bytes @ address 0x0000001A (Data = 0x0000) Read 2 bytes @ address 0x0000001C (Data = 0x0F55) Read 2 bytes @ address 0x0000001E (Data = 0x0000) Read 2 bytes @ address 0x00000020 (Data = 0x0F55) Read 2 bytes @ address 0x00000022 (Data = 0x0000) Read 2 bytes @ address 0x00000024 (Data = 0x0F55) Read 2 bytes @ address 0x00000026 (Data = 0x0000) Read 2 bytes @ address 0x00000028 (Data = 0x0F55) Read 2 bytes @ address 0x0000002A (Data = 0x0000) Read 2 bytes @ address 0x0000002C (Data = 0x0F55) Read 2 bytes @ address 0x0000002E (Data = 0x0000) Read 2 bytes @ address 0x00000030 (Data = 0x0F55) Read 2 bytes @ address 0x00000032 (Data = 0x0000) Read 2 bytes @ address 0x00000034 (Data = 0x0F55) Read 2 bytes @ address 0x00000036 (Data = 0x0000) Read 2 bytes @ address 0x00000038 (Data = 0x0F55) Read 2 bytes @ address 0x0000003A (Data = 0x0000) Read 2 bytes @ address 0x0000003C (Data = 0x0F55) Read 2 bytes @ address 0x0000003E (Data = 0x0000) GDB closed TCP/IP connection
I thought that disabling that breakpoint might be the cure. However, it is necessary to remove/delete that breakpoint. The same thing can happen if using an expression (see “Variable Debugging with Eclipse Kepler“) to ‘not-existing-anymore’ locations. Here again: the solution is to remove the expressions if this happens.
Sometimes the GDB gives an error back about breakpoint installation failed:
This warning is reported in the problems view too:
Removing the breakpoint from the breakpoint view does not help: I need to remove it from the ‘Problems’ view with the context menu:
With this, I get rid of that message :-).
Different GDB?
I tried the same thing with the GDB present in the GNU ARM Embedded (lauchpad) 4.8 update 2 gdb and tools, and here it was even more a problem: GDB is crashing:
Here the gdb traces are telling the internal GDB problem:
443,155 28-list-thread-groups 443,155 29-thread-info 1 443,226 ~"/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_fu\ ll: Assertion `state->canonical_names[i].suffix != NULL' failed.\nA problem internal to GDB has been\ detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? " 443,226 ~"(y or n) [answered Y; input not from terminal]\n" 443,226 ~"/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_fu\ ll: Assertion `state->canonical_names[i].suffix != NULL' failed.\nA problem internal to GDB has been\ detected,\nfurther debugging may prove unreliable.\nCreate a core file of GDB? " 443,226 ~"(y or n) [answered Y; input not from terminal]\n" 443,226 30-data-disassemble --thread 1 -s 2948 -e 3000 -- 1
I tried the same with the new v4.8 q3 update from launchpad. Here again it crashes, but gives at least some kind of information:
/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names[i].suffix != NULL' failed.
Summary
If there are breakpoint installation problems reported, remove the breakpoint from the Breakpoints view and delete the message from the Problems view. If you are using the GDB debugger (e.g. with the GNU ARM Eclipse plugins and/or Kinetis Design Studio), and if you cannot debug, then give it a try to delete your breakpoints and expressions. At least until this GDB bug gets fixed (I have submitted a bug report).
Happy Terminating 🙂
I noticed that using the “terminate and relaunch” menu between debugs works way better than when the debug is manually terminated/disconnected…
LikeLike
Yes, that usually works better as Eclipse (Kepler+CDT) knows the current debug configuration. There is a painful problem in CDT for selecting the debug/launch configuration with the menu or the ‘debug’ icon: if not using the drop down list, I see that sometimes it uses the wrong configuration which creates frustration.
LikeLike
Overall I am simply unimpressed with KDS (Ver 1.1.1) and its debugging (PE’s Multilink) with a K60 design. I have been battling for several hours with KDS debugging issues and it quite frustrating… probably as frustrating as your experience with your GDB bug.
In my case I continuing get the following error:
Error in final launch sequence
Failed to execute MI command:
-target-select remote 127.0.0.1:7224
Error message from debugger back end:
Remote communication error. Target disconnected.: No error.
Remote communication error. Target disconnected.: No error.
I have tried everything and yet it appears with regular consistency. I know my board, Multilink, etc are working correctly, as I do not have this issue with the PE Flash tools (i.e. I can connect and erase the flash, etc)…
Anyway… back to the Salt mines…
Cheers,
Sam
LikeLike
Hi Sam,
sorry for my late response, but: I get that same message if I try to debug again if there is already a debug session going on. Can you check that there is no debug session already running? Or that you have a zombie gdb running in the task list (Windows task manager)?
LikeLike
Pingback: Using Kinetis Design Studio V3.0.0 with the Launchad 4.9-2015-q2 Release | MCU on Eclipse
You are an angel!!!!! Thanks Erich.
LikeLike
not yet 😉
LikeLike
Hi Erich,
I have got a couple problems with debugging:
First one is just a major annoyance – often when I do terminate and relaunch after changing a few lines of code I get this:
>>>>>>>>>>>>>>
J-Link GDB Server failed:
Could not connect to target. Please check if target is powered and if ribbon cable is plugged properly.
For more details, see the JLinkGDBServerCL console.
>>>>>>>>>>>>>>>
For some reason a project never did this, and now it is doing it every time. The ‘fix’/workaround is easy, I just unplug/replug the USB to the j-link and try again, and that works every time.
I can live with this, but it is really annoying and seems to have no cause, on my laptop it happens about 1/2 the time. Different project on the desktop it didn’t happen for months, and now it is doing it all the time.
The second GDB problem is that I get this
>>>>>>>>>>>>>>>>>>>>>>
418,137 ~”/home/build/work/GCC-4-8-build/src/gdb/gdb/thread.c:615: internal-error: is_thread_state: \
Assertion `tp’ failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove un\
reliable.\nQuit this debugging session? ”
>>>>>>>>>>>>>>>>>>>
It appears that it may have been trying to execute from location 0 (the reset vector?)
but I don’t have a chance to single step the code and try to figure out what it is doing.
Have you come across either of these before, and do you have any solutions or ideas?
Brynn
LikeLike
Yes, I have seen similar things. And there were two different things which were creating this: in one case my J-Link EDU mini somewhow was damaged: it was really unreliable, I had to thrash it.
The other case was a bad USD cable. So I would try to exchange the USB cable, use differnt USB port, change the SWD/JTAG cable and finally change the J-Link (try another one) if this makes a difference. If not, it would be either on the host (IDE?, drivers?, reboot helps?) or on the target (bad soldering points? EMI?).
I hope this helps,
Erich
LikeLike
The problem that forces me to disconnect/reconnect seems like it must not be physical, because it worked for a long time without an issue, and suddenly I have the issue now all the time. [ I just went and switched to the exact USB cable that worked for months, and it made no difference. Also tried not going through the USB 3.0 hub I have been using for months, and that also made no difference.]
You know, there is one difference in the J-link that happened about the time the problem started – I installed MCUXpresso 11.0, and it reflashed the J-link to the latest version. [This problem is happening with KDS 3.2].
I just went and found a J-link that has firmware V9.40 and that does NOT have the disconnect/reconnect problem. The one with the problem was upgraded to firmware V10.10. For now I’ll have to try to keep one for MCUXpresso debugging and one for KDS, but maybe we should report it to Segger as a bug.
Brynn
LikeLike
I have seen issues coming and going away with different SEGGER firmware too.
The thing is that SEGGER changed the installation process and by default it installs into C:\Program Files (x86)\SEGGER\JLink on Windows now (previously it was using a dedicated folder for each firmware). So be sure to not install into the default.
In any case you can point MCUXpresso IDE to the SEGGER J-Link software you like:
Go to Window > Preferences > MCUXpresso IDE > J-Link Options and point to the JLinkGDBServerCL executable you like to use.
I hope this helps,
Erich
LikeLike
Now after switching to the earlier V9.40 J-link and ‘fixing’ the problem, switching back to the V10.10 J-link I find that the problem is now gone.
LikeLike
I think you might have encountered ‘DLL Hell’: mixing/using different J-Link DLLs by different tools might cause strange things. Because the DLLs might not be all compatible, and Windows might keep an old/newer version in RAM causing problems. SEGGER provides an update tool (JLinkDLLUpdater.exe, only on Windows) but this only will know about tools they know and are registered. The MCUXpresso IDE is different as it tries to use the latest version, so it is not listed there.
I recommend that you run the updater plus point the MCUXpresso IDE to the version you have ‘updated’.
LikeLike
Thank you it helped me out alot!
LikeLike
You are welcome! That problem was a nasty one for me too.
LikeLike