Failed to Debug with GDB: Breakpoints or Expressions on non-existing Locations

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:

Terminating Gracefully Target Disconnected

Terminating Gracefully Target Disconnected

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:

Breakpoint on non-existing Code

Breakpoint on non-existing Code

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:

Breakpoint attribute problem installation failed

Breakpoint attribute problem installation failed

This warning is reported in the problems view too:

Breakpoint Problem in the Problems View

Breakpoint Problem in the Problems View

Removing the breakpoint from the breakpoint view does not help: I need to remove it from the ‘Problems’ view with the context menu:

Deleting Breakpoint Attribute Problem

Deleting Breakpoint Attribute Problem

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:

GDB Crash

GDB Crash

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.
GDB Client Error Report

GDB Client Error Report

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 🙂

15 thoughts on “Failed to Debug with GDB: Breakpoints or Expressions on non-existing Locations

    • 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.

      Like

  1. 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

    Like

    • 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)?

      Like

  2. Pingback: Using Kinetis Design Studio V3.0.0 with the Launchad 4.9-2015-q2 Release | MCU on Eclipse

  3. 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

    Like

    • 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

      Like

      • 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

        Like

        • 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

          Like

        • 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.

          Like

        • 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’.

          Like

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.