- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is driving me mad. I cannot get the debugger to stay connected long enough to do any debugging! I constantly get errors of this type:
Error: dbg.M0007: The run request failed. Encountered error (Warning:
Cannot insert hardware breakpoint 1.
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
In the current setup I have but one breakpoint. What's really going on is that the debugger can't see the microprocessor. I have read all the posts I can find of this ilk, and I have the system set up for SWD debugging, no protection on the flash, which proved problematic for others. I am not debugging any sleep or low-power code.
Is there something amiss in my project (attached)?
Does anybody have a suggestion?
Environment:
PSoC Creator 4.2 (4.2.0.641)
Culture: English (United States)
OS Version: Microsoft Windows NT 10.0.17134.0
CLR Version: 4.0.30319.42000
Installed CyInstaller Products:
Peripheral Driver Library 3.0.1
PSoC Programmer 3.27.1
PSoC Creator 4.2
Thanks
Solved! Go to Solution.
- Labels:
-
PSoC 4 Architecture
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One thing I should have mentioned in my earlier post is that
once I downloaded the original project and encountered the debug problem,
even after downloading a new or other project, the debug problem remained.
So, to clear this problem I had to cycle the power of the board.
(I have on/off switch in my USB HUB)
Meantime, I noticed that in your project with "enabling Watchdog" is commented out,
you don't seem calling "CyGlobalIntEnable".
May be, it is worth trying to add this in the beginning of the main or some initialization function.
Although this may not be crucial, you can save a lot of heap size if you can go without "%f" format.
I posted following discussion about this, please take a look at it when you can.
printf and float rhapsody (aka, yet another printf and floating topic)
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Reinstallation did not seem to help at all. Bummer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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?
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No need for apology, Motoo - you have been very supportive. Time for the support request, I guess.
Thank you.
Edit: Heh - the MyCases page points back to the Community, so I guess I've gotten to the end of the road.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As you mentioned that you are not using BLE,
I could port your project to CY8CKIT-046 (PSoC 4 L).
And, yes, you problem could be reproduced!
I tried to fix the project for a while, but I could not make it work.
I created a brand new project and imported all your source files and headers.
Then I could debug your project, although some flags must have been missed!
Then I copied my CY8CKIT-046 project and re-target the project to your device.
I hope that this project can be debugged with you environment.
And after you confirm that you can debug the project,
please recover other build settings etc, you applied to your original project.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The pin configuration for the LEDs was correct. I didn't design the hardware . I'm evaluating the project in the meantime. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So I've downloaded the project you provided, rebuilt it for the 214015-01 processor, but I don't understand the point of the exercise. Your email indicates you created a new project, imported all of my source code, built it for CY8CKIT-046, and were able to reproduce the problem.
I'm probably missing something, but this sounds like I'm back to square one. And this week I'm working on this project again, so a debugger would be really helpful.
Thank you,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, I suspected 3 possibilities
(1) There was/were problem(s) within the source/header files
(2) There was a problem with the hardware
(3) There was a problem with the "Project"
Until I could build the project on my side, I could not be sure about (1)
Meantime (2) should be able to be confirmed with the previous PlainVanilla Project.
Then in your mention, I found that you are not using BLE this time,
now most of other stuff should be same with 4200L, so I downloaded your project
and re-target the device to 4200L, so that I could use the board I have for testing.
With that project, although error message was not exact, at least I could not debug at all.
This symptom happens when the project has some quite out of tune command file or
some part of the project is corrupted by some reason.
I've encountered some samples of project corruption with other vendors' MCUs.
So I created a brand new project and imported all of your source and header files
and tried to build. Fortunately the project was debuggable!
Then I copied the project and re-targeted the device to the one used in the original project
and re-configured pins to the original configuration.
All I could was up to confirm that this new project is "compile-able" but I had no way to test it.
So I attached the project to my previous message.
My current conclusion is that the original project was somehow corrupted,
but it will require more study to isolate the root cause.
And I'm very sorry but I can not afford time to study it.
I hope you can proceed your project with the newly created one.
And I'm glad if my hustle of this week could be a little help for you.
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for filling me in on what you did.
I pulled your project down and looked it over. I started a new project of my own - kind of in parallel with yours, but I've encountered problems.
In detail, I created an empty project, selected the correct processor, and with two copies of PSoc Creator running, copied the components on the .cydwr file (from the graphic representation - not the file itself), then verified that the pinouts, interrupts, clocks, and such were the same. Then I copied the .c and .h files over, added them to the project and built.
It built OK, and the debugger does seem somewhat less likely to disconnect randomly. The problem I'm seeing now is that a timer interrupt is not firing, so my system timebase is at a standstill. I loaded the original version of the firmware and the interrupt still doesn't fire, but it did yesterday. So I'm trying to chase that down. It should be dead-brain easy.
I attempted to use your project as-is, but the interrupt still didn't fire. The interrupt is based on an internal timer driven by a clock that is started at reset, and interrupts on overflow. It was pretty straightforward getting it to work initially. I don't know what has gone awry.
Thank you for your time and assistance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One thing I should have mentioned in my earlier post is that
once I downloaded the original project and encountered the debug problem,
even after downloading a new or other project, the debug problem remained.
So, to clear this problem I had to cycle the power of the board.
(I have on/off switch in my USB HUB)
Meantime, I noticed that in your project with "enabling Watchdog" is commented out,
you don't seem calling "CyGlobalIntEnable".
May be, it is worth trying to add this in the beginning of the main or some initialization function.
Although this may not be crucial, you can save a lot of heap size if you can go without "%f" format.
I posted following discussion about this, please take a look at it when you can.
printf and float rhapsody (aka, yet another printf and floating topic)
moto
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My board powers on and off enough where it's not a concern for me, but thank you for the information.
Yes, I neglected to enable interrupts when turning off the watchdog timer, but that's been fixed as well. Debugging with a watchdog is a whole different topic of conversation - it's best just to disable it after it's known to work.
Thanks for the hint on the printf. I'll keep that in mind if I run into a memory crunch.
While debugging is much, much improved with the project regeneration, it's still not what I consider "wonderful". It's currently usable, I guess. More debugging today.
Thank you again.