Setting all 8 breakpoints

Hello

I have a slide set from the Cortex-M3 Product Manager that clearly says 8 hardware breakpoints.
I don't see a place here where I can post the picture...

BUT ! We could both be correct - this maximum number could have been changed in a later version of CoreSight.....

I will ask the CoreSight guy and report back here what I find....

Thanks

Bob

I guess the pointy haired types do not ask "how many breakpoints" or the M0 I am currently working with would have had more than two. Of course the fact that the Freescale CodeWarrior allow you to think you have set as many as you want w/o any warning makes it even more fun.

Erik

OK, It still boils down to the same thing:

All of the devices (and this is true for both M3 and M4) have no more
than 6 breakpoints in the Flash patch unit.
The other 2 units hit on literal access, which means they can not be
used as breakpoints.

Bob:
I know you work for Keil/ARM and I understand you want to make
everything look good, but wrong is wrong. No bull please.
Try it out on any of the devices you mention above. You will find
that you have no more than 6 breakpoints. Some M3s actually have 2 only,
M0s in general have 4.
There is no M3/M4 device with more than 6 breakpoints that are usable
with ULINK.

My point remains.
Besides I find it irritating that I hear all of this:
"Nobody needs more breakpoints ... You can rewrite your code
and put them all in one subroutine ... J-Link's flash breakpoints
do not work either"

Can not hurt to have a lot of break points, there is no way to use
more than 6 on an M3/m4 device with ULINK. J-Links flash breakpoints
work well. Rowley's flash breakpoints are not as sophisticated, but they
also work well.

Please prove me wrong or change your specs.
BTW: Keil being an ARM company, why do not you fix the mentioned specs
for Cortex-M3 as well?

6 == 6 != 8

I am sorry you are having so much trouble setting break points on your Cortex M3. This must be very frustrating for you. Maybe you would like to tell us how this makes you feel?

It must also be frustrating that other people do not seem to be having such problems setting break points with the Cortex M3.

We really feel your pain.

Thanks for sharing...

John,

pleasure sharing it with all of you. Too bad none of you ARM & Keil guys care about false statements.
Ridiculing customers seems to be preferred ...

Great strategy, great company. I am impressed.

Hello,

Support does not actively monitor these forums, so this discussion slipped past me.

As pointed out, the ULINKs support 6 hardware breakpoints on a Cortex-M3 or Cortex-M4 device. All the documentation should have been updated to say this:

http://www.keil.com/ulink2/specs.asp

Some devices have more than 6 breakpoints, i.e as Cortex-R has 8 breakpoints. Cortex-M processors were the one that took off for mass market, and that is where the focus has been for the ULINK2 support.

Pedantically, the ULINK2 supports 8 breakpoints, but for practical purposes, a ULINK2 can only set the number of breakpoints the device supports i.e. 6 for a Cortex-M3 or Cortex-M4.

If there is a document on the site that has the wrong number of breakpoints, please let us know:

www.keil.com/.../supportRequest.asp
www2.keil.com/.../silver

Again we don't monitor this forum, so we may miss any comments left here. Any time we do read or post here, we are doing it on our own time, (since we play with the tools at home too).

Thanks

Perhaps you should just say it has 4, and offer 50% extra as a free bonus. Then everyone would be happily surprised, rather than bitterly disappointed.

If I got hung up every time when reality and documented behaviour or standard compliance weren't in 100% agreement nothing would ever get done. You've got to work with the cards you're dealt.

I'm sure if Samsung wanted a Cortex-M4 with 20 breakpoints they'd change the parameters on the CoreSight macro, and eat all the engineering costs, and additional silicon burden to make it happen.

For those of us without a Reality Distortion device, or limitless budgets, there are often easier, more creative solutions to the problems we encounter.

I often write code with:

if (unexpected_situation_found) {
    breakpoint_helper();
}
if (another_unexpected_situation) {
    breakpoint_helper();
}
if (yet_another_problem) {
    breakpoint_helper();
}

Then lots of unexpected situations can be handled by a single breakpoint in the breakpoint_helper() function - and stepping one step I'm back at the location it got called so I can see why I got a breakpoint and start to evaluate local variables.

Hmmm ...
I think if the manufacturer of the tool claims it can do 8 breakpoints,
it should be able to do so.
Being mocked and ridiculed by Keil/ARM support is very irritating.
Not letting the company look good.

Per is at least trying, so thanks for that.
But: In a lot of cases, I do not know where to set breakpoints
before the session, so I can not modify the code.
Besides, this is not great, I need to recompile, make sure I undo changes
when done, can not set them selectivly once I know one of these is not the problem.
It is a work around in some cases, but still not a new breakpoint.
I think only Segger (J-Link) can do it (any tool chain, even IAR & Keil), and to some extend Rowley.

test. I am having trouble posting....

I normally leave the breakpoint-helper function permanently in place, since it isn't part of the "happy path" of the code but there to let me figure out if processed data really was bad, or if it was a bug that made me reach that part of the code. And after the breakpoint helper call there is then normally logic to repair or fail or restart depending on why I believe the execution should reach that part of the code.

The other breakpoints are for making breakpoints in "happy path" locations, when actively debugging.

So it's only when the other breakpoints really aren't enough (quantity or quality) that I would consider recompiling with additional calls to the breakpoint helper function somewhere within the happy path - but potentially with some conditional test first, like "after 1000 iterations", or "if source IP is xx" or similar.

test

test

I think if the manufacturer of the tool claims it can do 8 breakpoints,
it should be able to do so.

Well, the tool can do it. It's the target that can't.

Being mocked and ridiculed by Keil/ARM support is very irritating.

Then it's a good thing that nothing of the sort actually happened.

OK, Specs are fixed, number of Breaks reduced to 6.

On Ridiculing customers, I think this is what has happend (see above)

<quote>
RE: Keil Specs are wrong. 6 !=8

I am sorry you are having so much trouble setting break points on your Cortex M3. This must be very frustrating for you. Maybe you would like to tell us how this makes you feel?

It must also be frustrating that other people do not seem to be having such problems setting break points with the Cortex M3.

We really feel your pain.

Thanks for sharing...
</quote>