Setting all 8 breakpoints

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.

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.

I did have it changed a long time ago: http://www.keil.com/ulink2/specs.asp

Hello

Last March this message timed out on me and I couldn't access it or even find it - I was waiting for someone to activate and now it looks like I have access ! Some sort of bug...
So - I did get the webpage fixed in march or so: www.keil.com/.../specs.asp
I asked them to change all other mention of the "8" - plus all my documents and I even told NXP about it as I saw they also used "8".
The confusion results from the ability using the Watchpoint feature (aka Access Breaks) to set two additional breakpoints. The regular 6 hardware breakpoints can be set/unset while the program is running. The instruction at the breakpoint address is not executed when it is encountered. This is an important feature.
The Watchpoint breakpoint, if I may call it this, must be set/unset when the program is stopped and it usually(always?) has some "skid". This is because these two types come from different parts of CoreSight. Someone, long ago, thought these are equal - and they are (sort of) , except for the skid.
I tried this and it doesn't seem possible to set just a Watchpoint breakpoint on just an executable address in uVision (MDK 5.13)(MCB1700). Not sure why. I will ask the engineer about this. But, of course, I can set 6 hardware breakpoints the normal way. Try 7 and uVision complains as it should.
If you know of anywhere else on keil.com that claims 8 - let me know. bob.boys@arm.com
BTW - it really isn't ULINK or J-Link that determines the number of hardware breakpoints - it is the chip itself.
Thanks
Bob San Jose, California