Setting all 8 breakpoints

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

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>

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

You're missing the point. Ridiculing may indeed have happened. But it was not, as you claim, ridiculing of customers by support. It was ridiculing of one forum participant by another forum participant.

I do not work for Keil. My opinions were my own. If you have a problem with that then your issue is with me, not with Keil.

I had trouble that someone was getting so bent out of shape with this. It did not seem like Keil was trying to pull a fast one on anyone. I have used, Ulink, Ulink2, ST-Link and Jlink and all of them support 6 break points on the Cortex M3. This is NOT a function of the JTAG device it is a function of the underlining hardware. These are HARDWARE break points and they reside in the hardware, not the JTAG device. IF the hardware supports 8 breakpoints, then ALL of these JTAG devices support 8 break points. If the hardware supports 6 then the JTAG devices support 6. Looking up the early documentation you can see that ARM was suggesting that they would support both 6 and 8 breakpoints in the this hardware line. This would depend on what the chip manufactures decided. Yes, as it has turned out, it seems that no one has made a device that supports 8 breakpoints, they all seem to be 6. But if the hardware DID support 8 breakpoints, I am quite sure that the Ulink2 would handle that. You seem to be complaining to Keil about the fact that the chip manufacturers did not support the 8 breakpoints. Keil can not fix that. I can understand that the course that was taken by ARM / the Chip manufacturers that it seems to be that we will never see 8 breakpoints for these chips. If Keil changes the documentation to say 6, that does seem reasonable at this point. It was not unreasonable for Keil to have claimed that they support 8. It was not reasonable to get so bent out of shape because Keil claimed that they supported the 8 breakpoints, as I am sure that they actually do support it. There was no hint that any chips would support higher than 8, so they did not claim something higher than 8, but my guess is that if it any chips did support more than 8, then the ULink2 would support more that 8 without changing the hardware (MAY require a firmware change, maybe not).

Keil did a great job on the Ulink2 (ok, the original manufacturing run was hosed, but it was still a good product). They really made an effort to match the Ulink2 documentation with the underlying hardware and try not to mislead anyone when they said 8 hardware breakpoints. They have said that they will change there current documentation to say 6 instead of 8, which given that no chips support the 8 also seems reasonable, but there does not seem to exist any intent to mislead or deceive on there part. That is why I claim that you have right to get so upset and bent out of shape.

Keil may not be your close friend, but they are not your enemy. They are not trying to deceive you. They they are trying to be helpful. Nothing that happened here should have made you upset or made you feel like you had been taken advantage of. You were not.