I tried similar thing with my current project.
At first I set 5 break points, then I tried start debug.
The debugger refused to start with similar dialog with yours.
So, I tried to delete all break points with the menu
Debug > Delete All Breakpoints
This allowed me to debug the program again, though all the break points were lost.
Thanks, Motoo, but it has nothing to do with breakpoints being over the limit (4?). In the particular case I'm working, I have only one breakpoint set, and I typically don't even need one, to reproduce this behavior.
Off my head the limit of hardware break point was 4, so I intentionally added 5.
At least with this I could reproduce a situation when I can not even start the debugger.
So I was wondering if there could be some unintentionally left over break points
somewhere in your project. And if it was the case, deleting all break points
could have changed the situation.
Meantime, although I could not reproduce it again, during my experimental of this issue,
one time I could set a break point where no mnemonic should have been generated
and with that break point, the debugger failed to start and similar dialog showed up.
(I tried to reproduce this but in vain)
If I remember correct, you also had problem with debugger behavior in another thread,
may be your PSoC Creator has got some damage.
Re-installing PSoC Creator may fix the problem, if you can afford time.
As usual, I'm sorry for not being helpful.
Reinstallation is an idea I'd not considered. It's always worth a shot. I find that it appears that a prior version of code debugs better, but I can't take that as fact yet, but I'll compare versions.
Reinstallation did not seem to help at all. Bummer.
Thank you for your taking time and pain.
And I'm sorry for another misjudgment.
BTW, Is this issue happening only with your current project?
In other words, can you debug other program/project without problem?
If it happens with other known good project, may be it's time to suspect hardware.
I tried to build your project the last line of compiler reports
Flash used: 59424 of 262144 bytes (22.7%).
SRAM used: 23684 of 32768 bytes (72.3%). Stack: 4096 bytes. Heap: 4096 bytes.
So you are using 4KB for Stack and 4KB for Heap
and you have about 9KB SRAM left.
I wonder how much elbow room BLE and your system requires,
there may be a memory shortage.
If that is the case, just for test,
how about reducing Stack size and Heap size and
see if it will affect the debugger or not?
BLE is not being used in this project. It was on the original plan, so we kept the same processor, but BLE is not turned on.
I have pushed the stack and heap both from 0x800 to 0x1000, with no change. I have no idea why one would decrease the stack or heap. I've never encountered a situation where the stack was too deep
Sorry, should have expand, but I don't know how much more we can/should expand.
Meantime, have you had chance to test with a simpler project which is known to be good?
In case you verified that your hardware (board, debugger, and PC) are fine,
I'd recommend you to submit a technical support request from
Cypress Home Page -> My account -> MyCases -> Get help -> Technical Support
And let me apologize you for not having forwarded you to the technical support earlier.
No need for apology, Motoo - you have been very supportive. Time for the support request, I guess.
Edit: Heh - the MyCases page points back to the Community, so I guess I've gotten to the end of the road.
Thanks, Bob, but nothing there seems to indicate a question to engineering. It seem appropriate if I have a questionable invoice or similar. There seems to be a strong push to get the questions into the Community. The only topics even in the ball park are "Customer Exception" and "Datasheet". Certainly this is an exception, but likely not one the site designers were thinking about.
I made a simple project to test your debug environment.
So please use this to confirm that your hardware (at least UART, LED and debug connection) is OK.
Meantime, during the course of creating this project,
I noticed that your LED pin configuration looks odd.
Your schematic suggests that your LEDs are pulled up and
LED_B, LED_G, LED_R should be negative logic.
But your pin configuration is
So I modified these to
May be your hardware requires positive logic to turn LEDs on,
then return these pin configs to Open drain, driving high or Strong drive.
Anyway, I hope that at least you can confirm that your debugging hardware is working.
PlainVanilla.cyprj.Archive01.zip 543.3 K