Debugger disconnects after code download

[bitjockey]

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

[davidsherman]

Thanks Erich, I tried using the "clean" option and rebuilding, but it had no effect on the issue I was seeing.  The only thing I'm leaning toward is it having files edited outside of KDS.  I had the map file and the suspect source file open in an outside text editor, and I wonder if that was causing problems.

[BlackNight]

Having the source file open should not matter at all. And if the file has been touched outside the IDE, Eclipse is pretty good to detect that. Where I had a problem in the past was that GDB was running as a zombie process (not terminated), and it kept the .elf file open. Rebuilding the files did not help, and the linker complained about the .elf file not accessible. Killing the gdb excecuable from the Windows task manager solved that problem :-)

[DavidLundquist]

Interestingly I've just run into the same exact issue.  My GDB Log is identical to what was posted earlier by David Sherman.  Using the PE Micro Multilink Universal. 

I had been making some very minor incremental code changes and this problem popped up.  Backing them out doesn't seem to get me back to a working config.

Confirmed that none of my GPIO configs are stepping on the SWD lines.  NMI is not enabled.

Anyone else seeing this have any advice beyond what David Sherman did to "reload" his

[roreith]

I think I just cured the same problem by doing Remove All breakpoints.

I haven't had a chance to reproduce the issue and test this fix, but I had already tried fiddling with the USB connection and P&E USB Multilink / OSBDM/OSJTAG setup in the debug configuration, restarting Kinetis Design Studio, restarting the PC, etc.

I have had gdb (arm-none-eabi-gdb.exe) keep running in the background sometimes (if this happens, perhaps try using the red square "Terminate" button on the console window), but that is not what was causing this disconnect-after-download issue. It makes sense to me that a badly-placed breakpoint could upset the CPU following reset. Hopefully some other users can shed more light on this?

[robcasey]

Another vote from me Ro Reith - Same problem and same solution.

In my instance, I am using KDS 2.0.0 with TWR-KV10Z32 connected via the OpenSDA Embedded Debug - USB Port.

[claybarclay]

Ro Reith, You are my hero,  I did everything for the same problem (hours lost) then found your post about removing all break points and bang!  I am off an running again!

thanks much:smileyhappy:

BTW I am using KDS 1.1.1 on a K60DN512Z no OS

[nickheppermann]

I too have just seen similar behavior to Ro Reith and Clay Barclay.  I am using PE Micro USB Universal Multilink to debug my firmware and it seems to work for a few hours and then just stop working, failing in the same manner as the original poster described.  Hopefully this is the only fix that is needed.

[BlackNight]

Does it happen as well if you download a simple/new project wizard created project?

Erich

[BlackNight]

could you post your console logs of the debugger?

What about using another board?

Power supply?

USB cable to the probe?

I had once a half-dead debug cable which had kind of same symptoms, so do you have a spare one?

Erich

[bitjockey]

Erich,

Thanks for the quick reply, I didn't reconfigure any pins. I took your advice and entered the _thumb_startup in my debug startup menu. Inadvertently forgot the second underscore at the beginning and when I started the debugger it operated as normal breakpointing at 'main'. Went back in and entered main in my debug startup breakpoint and it still works?!?! I looked to me that the debugger was not pointing to where the _thumb_startup code should be, or the startup code did not compile correctly or output into the elf file correctly....I will keep an eye on it, if it happens again I will try to isolate what is going on.

Brian