Setting all 8 breakpoints

Hello

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

Hello

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

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.

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.

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