Debugger exited unexpectedly after changing IDE host computer from Win 7 to Win 10

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JoRi_1316111
Level 3
Level 3
Welcome! 10 replies posted 5 replies posted

I've recently upgraded my PC from a Win 7 laptop to a Win 10 laptop. Nothing else has changed. (same miniprog 3, cables, target board, etc.) It's loaded up with the same version of PSOC Creator (PSoC Creator  4.2 (4.2.0.641)). My application software source is checked out from SVN compiles the same .hex file.

I've verified that:

  • I'm set to SWD debugging in the system settings
  • The debugger settings (SWD, 1.5 MHz, Reset, 10-pin, etc.) match my old PC.

Both computers load my application software with either the standalone programmer or PSoC Creator, but only the Win 7 computer will break in main(), sync up the debugger to source code. The Win 10 PC will do neither.

I've run the range of miniprog 3 frequencies and the best I was able to do is to get it to halt a the reset point after loading and it would only display in the disassembly tab.

I've surveyed old community posts, but I see nothing new to try. What else can be done?

0 Likes
1 Solution

So I finally got some time to pursue this. I SVN updated my project and did a clean/build and it still wouldn't run the debugger. My intention was to check out a fresh copy of the same project, build and test it and start stripping things out until it worked.

Seemed logical, except it worked the first time I built it . I did a recursive differences on the two working directories, but I'm unable to tell what the root cause is. They do both generate different .hex files, but it's not obvious to me why, as the source files appear identical. I'm going to delete my first working copy, declare victory and move on.

Thank you to everyone who tried to help.

View solution in original post

0 Likes
15 Replies
AnkitaS_51
Employee
Employee
100 likes received 50 likes received 25 likes received

Can you please uninstall and reinstall creator from this link:

http://www.cypress.com/products/psoc-creator-integrated-design-environment-ide

If you could attach the project, we will try to debug it in Win10 system to verify if it is genuine issue with project or creator on Win10 or it is system specific Windows issue

0 Likes

I uninstalled, rebooted (for good measure) then reinstalled. The symptoms stayed the same.

It wasn't very practical to send the project due to the proprietary target, so I verified that a very small test program exhibited the same problem and it did not.

I went back to my application and changed the breakpoint to "reset" instead of "main" and was able to step through Cm3Start.c until execution entered the __libc_init_array() library.

I'm unsure how to troubleshoot this. I'm guessing that perhaps we are trying to initialize an unintended region in the memory map, but I can't quite understand how my older PC and other developers' PC are able to function.

0 Likes

In case I wasn't clear, the reported symptoms appear immediately upon stepping into the library. It's completely repeatable.

0 Likes

I switched to the assembly mode debugger and was able to step into the library:
Capture.PNG

0 Likes

Can you just try the option"Attach to running Target" in Debug menu.

Can you just try taking the zipped file of project from a working system, then saving the project after unzipping in a different location (from previously saved location in C: drive) in your system with issue, sometimes this may help.

Meanwhile, can you check this link which discusses similar issue:

Debugger exited unexpectedly during run

0 Likes

Thank you for getting back to me. I won't be able to pursue this for a couple of days, but I will try out your suggestions and be getting back to you. I've read that that thread previously. I'm not using GPIO for debugging but I'll reread it carefully.

0 Likes

I did a minimal workspace bundle and extracted it to a new directory. I loaded the new project and it behaves the same way. After the initial failure from doing a "Debug", attempts to "Attach to Running Target..." fail because the "Attach to Target" dialog box shows no interfaces and a "Refresh" does not change the empty list.

After power-cycling the target board and reattempting the attach, the list of miniprog 3's is still empty.

When I perform a "Select Debug Target", the interface appears in the "Select Debug Target" dialog box and I'm able to select it and "connect".

Now a 3rd attempt at attaching to the running target's dialog box shows the interface. The debugger shows up in disassembly mode and the cursor is sitting on a blank first line right before 0x00000000 <RomVectors>:

call_stack_Capture.PNG

I reread the link you sent. I'm definitely using "SWD" for my debugger setting.

0 Likes

You said upgraded PC,  I assume you meant the hardware and OS, not just the OS.  And you tried reduced speed already. You should try another port, preferably one that is not USB3, or oven connecting through a USB hub that has it's own power. Also unplug any other USB devices you can. This is because I've seem some devices that don't like USB3 ports, and some PCs that have poor power on the port, either of these could cause your symptom.

0 Likes

Yes, hardware and O/S. I believe that I've tried all available USB ports on the laptop, but I'll verify this. I'll also see if I can turn up a powered hub.

0 Likes

All my ports are SS ports. All  behave identically. I tried a non-SS hub but the problem remains.

0 Likes

Are you able to debug in Creator  any Code Example in your system

0 Likes

I am able to compile, load and run an early target debugging program.

From what I've been able to see while stepping through initialization code while in assembly mode debugging, it appears to "trap" (for lack of a better word) when it goes to configure the clock. It's hard to say, for sure.

Symptomatically, there is something about this application firmware which "goes out to lunch" during initialization while using the debugger. It's probably timing-related to the extent that slower host computers don't exhibit the problem. It seems to me that I am going to need to discover some way to debug this, but at this point I don't know what that method is. In days gone by, I had ICE's and logic analyzers, but I'm somewhat blind here on this platform.

Is there some app note or white paper that describes how to debug an early-initialization trap or race condition?

0 Likes

@anks,

Thank you for the leads. I'm currently in a bit of a time crunch and am continuing to work with my old laptop, but as soon as I'm able, I will post back here the results of my debugging efforts.

Thanks for the information.

0 Likes

So I finally got some time to pursue this. I SVN updated my project and did a clean/build and it still wouldn't run the debugger. My intention was to check out a fresh copy of the same project, build and test it and start stripping things out until it worked.

Seemed logical, except it worked the first time I built it . I did a recursive differences on the two working directories, but I'm unable to tell what the root cause is. They do both generate different .hex files, but it's not obvious to me why, as the source files appear identical. I'm going to delete my first working copy, declare victory and move on.

Thank you to everyone who tried to help.

0 Likes