Debugger disconnects after code download

cancel
Showing results for 
Search instead for 
Did you mean: 

Debugger disconnects after code download

Jump to solution
4,185 Views
bitjockey
Contributor II

Hello,

 

I am using a KE06 freedom board an was compiling, downloading, and debugging with no problems. Yesterday when I had compiled and downloading software the PE debugger disconnects and does not end up at the main() breakpoint. I have taken a snapshot of the debug screen when this happens. I see that the error is "source not found 0x1ba8", if I look in the map file that address corresponds to thumb startup code (see snippet below), why would it not be able to find that? Isn't that automatically generated? I am using processor expert to generate the low level stuff....

 

.text.__thumb_startup

                0x00001ba8       0x48 ./Project_Settings/Startup_Code/startup.o

                0x00001ba8                __thumb_startup

 

Any help would be appreciated.

Thanks,

Brian

Labels (1)
1 Solution
1,186 Views
davidsherman
Senior Contributor I

Okay!  KDS does seem to be temperamental.  On a whim, I tried figuring out this error with the source file was about.  So, I copied it off, deleted it from the project, added a new source file with the same name, then copied over the old one.  Now, not only is the source file error message gone, but I can re-enable all the source lines and the debugger runs.  I can even make that pointer to the ROM structure again, and it's still good.  Crazy...  I'd log more bug reports about the strange things I've seen in KDS, like occasionally not being able to build at all because it says it can't write to temp files, but these things are so random I can't reproduce them.  Thanks for your assistance, Erich.  My apologies to the OP as well, I didn't mean to hijack your thread :smileysilly:.

View solution in original post

0 Kudos
30 Replies
976 Views
leifzars
Contributor IV

Same problem, removed all break points and it fixed the issue.

I saw   No source available for "0x0" and the debugging session would ended immediately.

0 Kudos
976 Views
claybarclay
Contributor II

Ok I figured out more about the issue that is plaguing us.  The reason we have to delete the break points is that they are on code that is not complied.  Yet the debugger does not know this.  This disconnect is causing the failed debug run.  I can get that but what is bugging me now is that I have code that will not compile.  It is not being optimized out.  The optimizers are all off.  I call a function from an event and the compiler compiles everything but that function call.  Since that was the only call to that function the compiler does not compile that function body either.  Sooo now I am reaching out for help on this new turn of events.  Why is this code not being compiled?

SOS my Freescale friends.

thanks

clay

0 Kudos
976 Views
BlackNight
NXP Employee
NXP Employee

I tried to replicate this on my side, but failed (did not see that debugger disconnect).

I think it is not related to if code is generated or not. I think what happens is this:

- gdb tries to set the breakpoint based on the breakpoint information (source line mapping to an address)

- that address is out of bounds or causes an exception on the target

- debugger disconnects

To further investigate this, could you post a screenshot of your breakpoints (if you still are able to see the issue)?

Additionally, the console view contains three dedicated logs for gdb traces, the gdb server and the ARM gdb:

pastedImage_0.png

They should contain information what is going on. Could you post the logs?

Thanks,

Erich

0 Kudos
976 Views
claybarclay
Contributor II

Hello Erich,

  Below is the information you asked for.  I suspect that this could be happening because the debugger thinks the function is associated with real program op codes in memory.  But it seems that for some reason this function has been left out of the binary.  It is called on place in the code and I think the compiler may have marked the function as unreachable.

Here is the code where it is called:

void sysTick_OnInterrupt(LDD_TUserData *UserDataPtr)

{

    // For now only need to increment system time here

    sysData.systime++;

    // Get the count

    if (sysData.systime & 0x01FF == 1)  // Count for 512 msecs

    {

        upateCndCount();

    }

}

bad breakpoints.jpg

Here are my logs:

717,869 2-environment-cd "P:/CS KDS Workspace/CSLillyPad"

717,885 2^done

717,885 (gdb)

717,885 3-gdb-set breakpoint pending on

717,900 3^done

717,900 (gdb)

717,900 4-enable-pretty-printing

717,900 4^done

717,900 (gdb)

717,900 5-gdb-set python print-stack none

717,900 5^done

717,900 (gdb)

717,900 6-gdb-set print object on

717,900 6^done

717,900 (gdb)

717,900 7-gdb-set print sevenbit-strings on

717,916 7^done

717,916 (gdb)

717,916 8-gdb-set charset ISO-8859-1

717,931 8^done

717,931 (gdb)

717,931 9set mem inaccessible-by-default off

set tcp auto-retry on

set tcp connect-timeout 30

717,931 10source .gdbinit

717,947 &"set mem inaccessible-by-default off\n"

717,947 =cmd-param-changed,param="mem inaccessible-by-default",value="off"

717,947 9^done

717,947 (gdb)

717,947 &"set tcp auto-retry on\n"

717,947 ^done

717,947 (gdb)

717,947 11-gdb-set auto-solib-add on

717,947 &"set tcp connect-timeout 30\n"

717,947 ^done

717,947 (gdb)

717,947 &"source .gdbinit\n"

717,947 &".gdbinit: No such file or directory.\n"

717,947 10^error,msg=".gdbinit: No such file or directory."

717,947 (gdb)

717,947 11^done

717,947 (gdb)

717,947 12-target-select remote 127.0.0.1:7224

717,978 13-list-thread-groups

718,477 =thread-group-started,id="i1",pid="42000"

718,477 =thread-created,id="1",group-id="i1"

718,477 14-list-thread-groups --available

718,493 *stopped,frame={addr="0x000029c0",func="??",args=[]},thread-id="1",stopped-threads="all"

718,493 12^connected

718,493 (gdb)

718,493 &"\n"

718,493 ^done

718,493 (gdb)

718,493 15flushreg

718,493 13^done,groups=[{id="i1",type="process",pid="42000"}]

718,493 (gdb)

718,493 14^error,msg="Can not fetch data now."

718,493 (gdb)

718,493 &"flushreg\n"

718,493 ~"Register cache flushed.\n"

718,524 15^done

718,524 (gdb)

718,540 16monitor semihosting 0,51794

718,555 &"monitor semihosting 0,51794\n"

718,555 @"Command Executed successfully: semihosting 0,51794\r\n"

718,555 16^done

718,555 (gdb)

718,555 17symbol-file "P:\\CS KDS Workspace\\CSLillyPad\\Debug\\CSLillyPad.elf"

718,555 18load "P:\\CS KDS Workspace\\CSLillyPad\\Debug\\CSLillyPad.elf"

718,555 19-list-thread-groups i1

718,571 &"symbol-file \"P:\\\\CS KDS Workspace\\\\CSLillyPad\\\\Debug\\\\CSLillyPad.elf\"\n"

718,571 ~"Reading symbols from P:\\CS KDS Workspace\\CSLillyPad\\Debug\\CSLillyPad.elf..."

718,649 ~"done.\n"

718,665 17^done

718,665 (gdb)

718,665 &"load \"P:\\\\CS KDS Workspace\\\\CSLillyPad\\\\Debug\\\\CSLillyPad.elf\"\n"

718,665 20-gdb-show --thread-group i1 language

718,665 ~"Loading section .interrupts, size 0x1e0 lma 0x0\n"

718,665 18+download,{section=".interrupts",section-size="480",total-size="906415"}

718,665 18+download,{section=".interrupts",section-sent="480",section-size="480",total-sent="480",to\

tal-size="906415"}

718,665 ~"Loading section .cfmprotect, size 0x10 lma 0x400\n"

718,665 18+download,{section=".cfmprotect",section-size="16",total-size="906415"}

718,665 ~"Loading section .text, size 0x7540 lma 0x410\n"

718,665 18+download,{section=".text",section-size="30016",total-size="906415"}

718,696 ~"Loading section .init_array, size 0x4 lma 0x7950\n"

718,696 18+download,{section=".init_array",section-size="4",total-size="906415"}

718,696 ~"Loading section .fini_array, size 0x4 lma 0x7954\n"

718,696 18+download,{section=".fini_array",section-size="4",total-size="906415"}

718,696 ~"Loading section .data, size 0xe8 lma 0x7958\n"

718,696 18+download,{section=".data",section-size="232",total-size="906415"}

718,696 ~"Loading section .romp, size 0x24 lma 0x7a40\n"

718,696 18+download,{section=".romp",section-size="36",total-size="906415"}

721,350 ~"Start address 0x2988, load size 30788\n"

721,350 ~"Transfer rate: 11 KB/sec, 905 bytes/write.\n"

721,350 18^done

721,350 (gdb)

721,365 19^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x00002988",func="\

__thumb_startup",args=[],file="../Project_Settings/Startup_Code/startup.c",fullname="P:\\CS KDS Work\

space\\CSLillyPad\\Project_Settings\\Startup_Code\\startup.c",line="211"},state="stopped"}]

721,365 (gdb)

721,365 20^done,value="auto"

721,365 (gdb)

721,365 21-gdb-set --thread-group i1 language c

721,365 21^done

721,365 (gdb)

721,365 22-data-evaluate-expression --thread-group i1 "sizeof (void*)"

721,365 23-stack-info-depth --thread 1 11

721,365 22^done,value="4"

721,365 (gdb)

721,365 24-gdb-set --thread-group i1 language auto

721,365 23^done,depth="1"

721,365 (gdb)

721,365 24^done

721,365 (gdb)

721,365 25-interpreter-exec --thread-group i1 console "show endian"

721,365 ~"The target endianness is set automatically (currently little endian)\n"

721,365 25^done

721,365 (gdb)

721,381 26-break-insert --thread-group i1 -f "\"P:\\CS KDS Workspace\\CSLillyPad\\Sources\\sensor.c\\

":27"

Second one:

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.2.201408071632\win32\gdi\unit_ngs_arm_internal.dll ... Done.

Command line arguments: -device=K60DN512Z -startserver -serverport=7224 -interface=USBMULTILINK -speed=5000 -port=USB1 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MASS_ERASE=0

Device selected is k60dn512z

User Specified Hardware Selection : Interface=USBMULTILINK and Port=USB1

Connecting to target.

P&E Interface detected - Flash Version 6.10

Device is K60DN512Z.

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.2.201408071632\win32\pegdbserver_console -device=K60DN512Z -startserver -serverport=7224 -interface=USBMULTILINK -speed=5000 -port=USB1 -USE_CYCLONEPRO_RELAYS=0 -FORCE

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.2.201408071632\win32\gdi\P&E\k60dn512z_pflash_pipeline.arp

Initializing.

Initialized.

;version 1.12, 07/17/2013, Copyright P&E Microcomputer Systems, www.pemicro.com [mk_512k_n_pflash0_pflash1]

;device freescale, k60dn512z, 1x32x128k, desc=pflash_pipeline

;begin_cs device=$00000000, length=$00080000, ram=$20000000

Loading programming algorithm ...

Done.

CMD>EM

Erasing.

Module has been erased.

Initializing.

Initialized.

;version 1.12, 07/17/2013, Copyright P&E Microcomputer Systems, www.pemicro.com [mk_512k_n_pflash0_pflash1]

;device freescale, k60dn512z, 1x32x128k, desc=pflash_pipeline

;begin_cs device=$00000000, length=$00080000, 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-000001DF ...

Ok.

   block 00000400-00007A63 ...

Ok.

   Checksum Verification Successful. (Cumulative CRC-16=$92B0)

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.

Third one:

The target endianness is set automatically (currently little endian)

0 Kudos
976 Views
BlackNight
NXP Employee
NXP Employee

I think you wanted to write

if ((sysData.systime & 0x01FF) == 1)  // Count for 512 msecs

?


Erich

976 Views
claybarclay
Contributor II

Erich,  Yeah I found that one so I know why the code was unreachable, but that just gets me back to the issue at hand.  Why does this tool allow breakpoints set on unreachable code to cause the debugger to fail without any warning.  CodeWarrior would let you know if the requested breakpoint was not reachable and effectively disable it.  I guess now that I know about this bug I am going to be ok by working around it, but I warn my fellow developers out there about this strange failure mode in KDS 1.1.1  And if you hear about a fix please let me know.

  thanks

  clay

0 Kudos
976 Views
BlackNight
NXP Employee
NXP Employee

Clay,

without a doubt, this is not how gdb should deal with this. I tried to reproduce it on my end, but I was not able to. Not sure what specifics are behind it making it fail.

Erich

0 Kudos
976 Views
marks
Contributor IV

Woo Hoo! Deleting all breakpoints worked for me!


Thank, Mark

0 Kudos
976 Views
BlackNight
NXP Employee
NXP Employee

ah! So it is really the problem described here: http://mcuoneclipse.com/2014/10/11/failed-to-debug-with-gdb-breakpoints-or-expressions-on-non-existi...

I already have submitted a bug ticket to ARM about this.

976 Views
davidsherman
Senior Contributor I

Good catch, Erich.  Without the parentheses, his expression would always be false.

0 Kudos
981 Views
BlackNight
NXP Employee
NXP Employee

Few ideas:

- does your application change/remap the debug pins? If your application cuts of the debug pins, then the debugger will loose connection.

  Check if you have not used debug/SWD pins for your application.

- don't run to main(). Instead, set a breakpoint for your startup code:

pastedImage_0.png

I assume that you will be able to step through your startup code, and then you should be able to see what is causing the problem.

- check the various console output and log for debugging:

pastedImage_2.png

There might be a hint in it what is causing this.

I hope this helps,

Erich

0 Kudos
981 Views
davidsherman
Senior Contributor I

I was about to ask a similar question, I'm suddenly experiencing the same problem.  I'm using MQX Lite.  What's strange is if I comment out a function call in one line in one of my MQX tasks, it works.  This line previously worked, however, and I haven't modified the function being called.  What's also peculiar is if I comment the body of the function out so it does nothing, it still has problems.  I can't seem to change the startup point to __thumb_startup, either.  I just get the message saying "No source available for 0x410", which appears to be __boot.  If I try to change the startup to __boot, it works IF I don't have that line enabled, otherwise it says "__boot" is not defined.  Very strange.

0 Kudos
981 Views
BlackNight
NXP Employee
NXP Employee

It looks like the device made a reset or a hard fault. There can be many reasons for this, like accessing illegal instructions, stack overflow,.... or that the watchdog triggered (not sure if this is enabled).

Do you have the hard fault handler enabled so you know if this is not your problem?

After you get that 'no source available', try to do an assembly single step. GDB loads the PC from the reset vector (you should see it in the registers view), but sometimes does find the source for it. Doing a step ensures that everything is updated.

0 Kudos
981 Views
davidsherman
Senior Contributor I

Thanks Erich, but I can't single step because the debugger disconnects before it even starts to debug.  I have checked the hard fault handler box, but it makes no difference.  I'm not using the watchdog timer.  I'm just scratching my head because it dies without even entering main(), so it's hard to tell what's happening.  If it is overflowing the stack, how do I tell?

0 Kudos
981 Views
DavidS
NXP Employee
NXP Employee

Hi David,

Is this on the FRDM-KL25Z board or your own design?

Other suggestions to add to Erich's for your own design:

Please check that the NMI pin is disabled and the NMI pin has a pull-up.

RESET has strong pull-up.

Is code trying to initialize RTC and not RTC clock present?

Is debugger firmware updated?  What debugger hardware are you using?

Regards,

David

0 Kudos
981 Views
davidsherman
Senior Contributor I

I don't think it's a USB cable problem, I can comment out one line and it works fine.  The problem seems to be related to a structure defined in ROM.  If I even declare a pointer to point to it, it has this problem.  I have tried two different FRDM-KE06Z boards.  The board I was developing on has been modified with an external 48 MHz oscillator and a SPI eeprom attached to the SPI0 signals, but works fine with other applications.  I already found out about the NMI pin when I discovered it was shared with the SPI signal, so it is disabled now.  I have been using a P&E Multilink Universal FX debugger.  I tried another FRDM-KE06 board, new out of the box, and used the OpenSDA interface through a different USB cable, but it does exactly the same thing.  If I comment out the line, it starts debugging.  It occurred to me, is there a code size limit I've reached that limits debugging?  The line of code in question worked previously, but I've been porting code into other modules.  Here's the GDB log:

P&E GDB Server, Version 2.02.00.01

Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

Loading library C:\Freescale\KDS_1.0.1\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.4.201404181439\win32\gdi\unit_ngs_arm_internal.dll ... Done.

Command line arguments: -device=KE06Z128M4 -startserver -serverport=7224 -interface=OPENSDA -port=USB1 -speed=5000 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MASS_ERASE=0

Device selected is ke06z128m4

User Specified Hardware Selection : Interface=OPENSDA and Port=USB1

Connecting to target.

OpenSDA detected - Flash Version 1.14

Device is KE06Z128M4.

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.0.1\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.4.201404181439\win32\pegdbserver_console -device=KE06Z128M4 -startserver -serverport=7224 -interface=OPENSDA -port=USB1 -speed=5000 -USE_CYCLONEPRO_RELAYS=0 -FORCE_MAS

CMD>RE

Initializing.

Target has been RESET and is active.

CMD>CM C:\Freescale\KDS_1.0.1\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_1.0.4.201404181439\win32\gdi\P&E\ke06z128m4_pflash_pipeline.arp

Initializing.

Initialized.

;version 1.02, 02/07/2014, Copyright P&E Microcomputer Systems, www.pemicro.com [ke_128k_pflash_ftmre_m0]

;device freescale, ke06z128m4, 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.02, 02/07/2014, Copyright P&E Microcomputer Systems, www.pemicro.com [ke_128k_pflash_ftmre_m0]

;device freescale, ke06z128m4, 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-0000A7C3 ...

Ok.

   Checksum Verification Successful. (Cumulative CRC-16=$2F55)

CMD>RE

Initializing.

Target has been RESET and is active.

Disconnected from "127.0.0.1" via 127.0.0.1

CTRL-C Pressed. Terminating Gracefully...

Target Disconnected.

0 Kudos
981 Views
BlackNight
NXP Employee
NXP Employee

No, that's not a code size limit. If you would reach that, it will not download and let you know.

About that pointer to that ROM location: is that a special area? It looks if you have that pointer, that memory gets refrenced (and linked).

And then it gets downloaded/flashed to that area. It looks to me that this causes something bad with the processor somehow.

It could be the P&E Multilink? Try if the same happens if you use the OpenSDA. If yes, you might try it with the Segger J-Link firmware (just to make sure it is not a P&E issue):

Freedom Board with Segger OpenSDA Debug Firmware | MCU on Eclipse

Erich

0 Kudos
981 Views
davidsherman
Senior Contributor I

There shouldn't be anything special about that area, it just has const qualifiers that place it in ROM, which I've confirmed in the linker map.  I haven't defined any specific linker sections.  As I've already said, it does exactly the same thing using OpenSDA.  Now things have a new wrinkle.  I had disabled some lines while troubleshooting this.  Now that I've re-enabled them, this problem has shifted to another line, a call to a function which contains _int_install_isr().  If I comment that line, it starts debugging, and with it enabIed it refuses to start.  Again, it does this on two different boards, using both OpenSDA and the Multilink.  The only other quirk I noticed is that KDS is complaining about not being able to find a source file, which has the function in question.  The source file does exist, and I can open it from within KDS, so I'm not sure why the console is now reporting "No source file".

0 Kudos
1,187 Views
davidsherman
Senior Contributor I

Okay!  KDS does seem to be temperamental.  On a whim, I tried figuring out this error with the source file was about.  So, I copied it off, deleted it from the project, added a new source file with the same name, then copied over the old one.  Now, not only is the source file error message gone, but I can re-enable all the source lines and the debugger runs.  I can even make that pointer to the ROM structure again, and it's still good.  Crazy...  I'd log more bug reports about the strange things I've seen in KDS, like occasionally not being able to build at all because it says it can't write to temp files, but these things are so random I can't reproduce them.  Thanks for your assistance, Erich.  My apologies to the OP as well, I didn't mean to hijack your thread :smileysilly:.

View solution in original post

0 Kudos
981 Views
BlackNight
NXP Employee
NXP Employee

Hi David,

well, the important thing is that you are up and running again. Still it concerns me, because clearly things should not be that way. Maybe somehow your object file got corrupted? You can do a complete re-build with Project > Clean and then build, or simply delete the 'Debug' (or whatever name it has) output folder.

I know that I had once an issue that some files of my project were compiled for M4, but the rest for M0+: all kind of strange things happened when I tried to run that code in the Cortex M0+ :-(

Erich

0 Kudos