Hi everyone,
I am debugging an application on a STM32F4 in flash with a ULINK. I read one of the features for the ULINK should be 8 breakpoints, but after the 6th breakpoint I get an error message. Isn't it possible to use all 8 breakpoints? Maybe can I use 8 breakpoints with another device?
Can you help me with this?
Warden
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 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
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
Hi Bob,
You are wrong. The maximum is 6, not 8. Higher up in this thread you see the following:
About the Flash Patch and Breakpoint Unit (FPB) ... A full FPB unit contains: ... - Six instruction comparators for matching against instruction fetches from Code space, and remapping to a corresponding area in System space. Alternatively, you can configure the comparators individually to return a Breakpoint Instruction (BKPT) to the processor core on a match, to provide hardware breakpoint capability. The ARM manual clearly says: 6 is the max. Please have this fixed. It is simply wrong.
Thanks Bob
Parking routines in RAM should also permit breakpointing in a similar fashion to the flashing mechanism of the J-Link. Sure it might take a bit more effort to set up the test cases, but when encountering limitations it helps to get creative rather than whining.
In a Cortex-M processor it is possible to have anywhere from two to 8 hardware breakpoints. How many there really are is chosen by the silicon OEM such as ST or NXP etc. These choices are sometimes made between features and die real estate.
The STM32F4 has 6 - I have seen one or two parts with 8 - I can't remember which ones. But 6 is the most popular.
A ULINK will work with 8 - I have done this...but if the chip has only six - this is all it will/can work with.
uVision (and probably all other debuggers) use breakpoints for its own uses...I believe these are generally not taken away - but uVision will set/unset these dynamically as needed. Run to Main is one example I can think of. But generally, they are all available to you.
These are the ARM CoreSight hardware breakpoints: you can set/unset them while the program is running and they are non-skid...this means they don't execute the instruction they encounter on a match. These do not work above 0x2000_0000 (I think this is the address). Most (all) flash is at the bottom of the memory so it doesn't matter much.
As far as re-flashing memory - J-Link does this - I believe it inserts a BKPT instruction. You can many of these. This was very useful with ARM7 and ARM9 which had only two hardware breakpoints. Does it do this with Cortex-M ? The disadvantage of this is it changes your memory contents (as do software breakpoints) and some people have had serious problems with this method - a bug goes away or is introduced. ULINK does not support this method. uVision supports the J-Link method with ARM7 and ARM9 - not sure about Cortex - I never tried this.
If you want more breakpoints - you can try Watchpoints (Keil calls these Access Breaks). For address matching you can set two or four (depends I think). There is usually a small skid of an instruction or two...and a Watchpoint doesn't burn CPU cycles doing the test. Nor do the hardware breakpoints. Watchpoints can be set anywhere in memory if I remember correctly.
Bob Boys ARM
Warden:
It simply is not possible with U-Link. You do need to change the content of flash memory if you need more than 6 breakpoints in internal flash. I do not know why others (below) do not just admit it, and instead say something like "just simulate" or "who needs breakpoints nowadays". If you need more breakpoints, you need an other probe. Rowley has something like that, Segger's J-Link seems to be best in class.
The limit is 6 breakpoints, calling it 8 is simply wrong. Trying to say: Oh you do not need breakpoints, you can simulate etc. does not make it any more true.
Besides: The way I work I need a lot of breakpoints. Reminds me of my old boss, who said: Debuggers are only for sloppy programmers...
How many get eaten with reset, run-to-main, stepping, or other housekeeping purposes?
Perhaps flow might be better exposed via telemetry rather than abruptly grinding to a halt in a debug terminal?
Per,
My processor is an older STM32F1, so it is an M3, but I think for both M3 and M4: I am not aware of any Cortex-M3 or M4 that has more than 6 Flash patch units that can be used. Can you name even one Cortex-M device on which the 8 Breakpoints can actually be set? If you can not, should not the "8 max" be changed?
"Keil promises 8 ROM breakpoints here:"
Actually, no they don't.
They promises "8 max" (note that 8 max often means something else than 8 - "8 max" often means "up to", indicating that there may be other factors making the practical limit lower).
And the above promise is for Cortex-M3 - isn't your processor a Cortex-M4? Where in that table do you see any promises for Cortex-M4 besides the check for "Supported Device Families"?
Let's say Keil promises that their hardware can be used up to 100MHz processors. If you then buy a 20MHz processor - would Keil then be wrong in their promises?
Keil specifies the capability of their JTAG adapter. But that doesn't mean the actual capabilities available to you will depend on which processor you connect it to. Guess what? If the processor haven't any JTAG interface, then you get zero breakpoints...
Same with the trace functionality - you only get trace functionality when using a processor that have trace support. But Keil can still list trace functionality for the adapter.
Now you are saying I do not need them because I should simulate? absolutely not!
I need as many breakpoints as I can get. we all do.
I, often have a small function
global variable bool Ralphie; // made global to avaoid function optimized out void ralph (void) { Ralphie = TRUE; // set breakpoint here }
and make a call to ralph in the places I know I'll need to break at for a while
... efficient using JTAG debug, I'm sure you can have 8 breakpoints. Since the SIMULATOR is pure PC code it can have as many breakpoints as the developer decided to include.
So I cannot use 8, but only 6 breakpoints?
If I understand the Cortex-M4 Technical Reference Manual correctly, you should expect a maximum of 6 breakpoints.
About the Flash Patch and Breakpoint Unit (FPB) ... A full FPB unit contains: ... - Six instruction comparators for matching against instruction fetches from Code space, and remapping to a corresponding area in System space. Alternatively, you can configure the comparators individually to return a Breakpoint Instruction (BKPT) to the processor core on a match, to provide hardware breakpoint capability.
Other debugging facilities in the Cortex-M4 may provide a hardware breakpoint capability as well, but I didn't look into that.
View all questions in Keil forum