Debugger disconnects

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

cross mob
lock attach
Attachments are accessible only for community members.
JoGr_3357391
Level 4
Level 4
10 likes given 5 likes given First like received

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

0 Likes
1 Solution
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

View solution in original post

0 Likes
21 Replies
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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.

000-5-break_points.JPG

So, I tried to delete all break  points with the menu

Debug > Delete All Breakpoints

005-delete_all_breakpoints.JPG

This allowed me to debug the program again, though all the break points were lost.

moto

0 Likes

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.

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

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.

0 Likes

Reinstallation did not seem to help at all. Bummer.

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

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

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

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.

0 Likes

Try this link.

Bob

0 Likes

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.

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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.

LED_Circuit.JPG

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

LED_B_OD_H.JPG

So I modified these to

LED_B_OD_L.JPG

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

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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!

000-Debug-Error.JPG

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

0 Likes

The pin configuration for the LEDs was correct. I didn't design the hardware . I'm evaluating the project in the meantime. Thanks

0 Likes

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

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

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.

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

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

0 Likes

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.

0 Likes