This site will be closed on 31 December 2015,
This site is for users of Code Red branded products.
NXP LPCXpresso users should visit the LPCXpresso FAQ's for up-to-date information relevant to that product.
When debugging code that is running from flash memory, the debugger is limited on how many breakpoints it can set at any time by the number of hardware breakpoint units that are provided by the ARM CPU within the MCU. Links to ARM's CPU documentation can be found here. Note that breakpoints and watchpoints consume the same internal resources.
Typically, the number of breakpoints that can be set are as follows:
Cortex-M0/M0+ - 4 breakpoints
Cortex-M3/M4 - 6 breakpoints
ARM7/ARM9 - 2 breakpoints
though ARM does provide a level of flexibilty to the MCU vendor, so always consult your MCU documentation. In particular note that the Freescale Kinetis KL Cortex-M0+ parts only provide 2 breakpoints.
If you try to set too many breakpoints when debugging, then you will see the following error...
15: Target error from Set break/watch Unable to set an execution break - no resource available.
Also remember that a breakpoint will be (temporarily) required for the initial breakpoint set by Code Red IDE by default on the function main() when you debug your application. For more details of this, please see the FAQ Changing the initial breakpoint on debug startup.
A breakpoint will also be required (temporarily) when single stepping your code.
On ARM7 based systems, also be aware that if semihosting functionality is being used, then this will consume one breakpoint, leaving only one for general use.
When viewing source (or disassembly) during a debug session, you can toggle breakpoints by simply clicking/double clicking in the left most side of the source view, typically shown as a light blue column. This is also where the breakpoint symbol is shown when one is set.
As well as being marked in the source view when debugging, breakpoints are displayed, and can be deleted, in the Breakpoints View. If you are using the "Debug" perspective for debugging, then by default this will be in the top right of the Code Red IDE window (though it will be tabbed with a number of other views). If you are using the "Develop" perspective, then by default it will be in the bottom left of the Code Red IDE window (again tabbed with other views).
If you have closed the Breakpoint view at some point, then you can reopen it using the "Window -> Show view" menu.
You can use the "Skip all breakpoints" icon in the Breakpoints view (or on the main toolbar) to temporarily disable all breakpoints. This can be particularly useful on parts with only a few breakpoints available, particularly when you want to reload your image, which will typically cause the default breakpoint on main() to be temporarily set again automatically by the tools.
One other thing to watch is that breakpoints are stored in the workspace, and by default are effectively project independent. Thus if you set a breakpoint in one file, and have a file of the same name in another project within the workspace, then if you debug the second project you may hit breakpoints unexpectedly (or have all your breakpoint units consumed unexpectedly).
You can configure your debug launch configuration such that breakpoints are set with absolute filenames to avoid this issue though.
To do these, right click on the project and select...
Launch Configurations -> Open Launch Configurations -> Debugger
Then select the "Main" tab and tick the "Use full file path to set breakpoints" option.
Note - this assumes you have already debugged the project in question. If not simply select the "Create Launch Configurations" option first.