Setting all 8 breakpoints

What error message, exactly, do you get?

Breakpoints are normally registered in special debug cells in the processor you use, to allow the processor to run at full speed and break execution if the current address matches any of the debug cells.

Using more breakpoints than the processor have hardware support for would require the flash memory to be reprogrammed to replace processor instructions with some instruction that will trig an exception. This would obviously only result in a simple code execution breakpoint, while the debug cells can have lots of nice configuration to only break on special accesses - such as writing a specific value, or break after n accesses.

A good way to reduce the number of breakpoints needed is to let code call a potentially empty error function where you set a single breakpoint. The call stack can then tell from where the program execution came.

The error I get is: 'Cannot set breakpoint. All hardware breakpoints in use.'

So I cannot use 8, but only 6 breakpoints?

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.

... 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.

Erik

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

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.

"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"?

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?

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?

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...

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.

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.