winIDEA HelpOverview
In this topic:
Introduction
Breakpoints are intentional stops marked in the code of an application, where execution pauses for debugging purposes. They can be triggered based on conditions, specific lines of code, or instructions.
For a quick overview and convenient manipulation of the breakpoints during debugging, take a look at the Breakpoints window. Breakpoints are used in an Editor, Disassembly Window and Breakpoints window. A simple Wizard allows you to configure Hardware Breakpoint either as an execution or access breakpoint.
Hardware Breakpoints
Hardware breakpoints offer a fast and responsive debugging experience, leveraging the capabilities of your CPU. Unlike software breakpoints, which involve modifying the program's code, hardware breakpoints are implemented using on-chip debug logic provided by the CPU itself.
By default, winIDEA is using Hardware Breakpoints. It automatically configures the breakpoints with appropriate qualifiers, simplifying the debugging process. Open Debug / Hardware Breakpoints to manually configure the hardware breakpoints.
The number of hardware breakpoints is limited and depends on the specific CPU core. Most modern microcontrollers provide at least four hardware breakpoints, which is generally sufficient for basic debugging purposes. Some CPUs may offer more, such as eight, twelve, etc.
|
Some high-level debugging functionalities, such as source step, need one hardware breakpoint to function properly. To overcome the problem with these functionalities, winIDEA reserves one hardware breakpoint for high-level debugging. If you are sure you know what you are doing, you can free this breakpoint via option Reserve one breakpoint for high-level debugging in the Debug / Options / Debugging. |
Hardware breakpoints are breakpoints that are already provided by the CPU. The number of hardware breakpoints is limited to four or eight, twelve, etc. depending on the core. The advantage is that they function anywhere in the CPU space, which is not the case for Software Breakpoints, which normally cannot be used in the FLASH memory, non-writable memory (ROM) or self-modifying code. If hardware breakpoints are selected, only hardware breakpoints are used for execution breakpoints.
Execution Breakpoints
Used to stop code execution at the breakpoint before the code on that line is executed. Open Debug / Breakpoints for Execution Breakpoints dialog. For more information, refer to Execution Breakpoints.
Conditional Breakpoints
Conditional Breakpoints specify the number of times the breakpoint is passed or/and the C expression evaluation matches until it activates. This breakpoints do not operate in real-time. You can set a conditional breakpoints via Debug / Breakpoints / Condition. For a step-by-step tutorial refer to Set a Conditional Breakpoint on the Xth pass.
Access Breakpoints
Access Breakpoints stops code execution when a specific memory is accessed. For more information, refer to Access Breakpoints.
Software Breakpoints
You can use software breakpoints by enabling:
•Hardware / Use Software Breakpoints / <coreID> or
•Core-specific option in the Hardware / CPU Options / <coreID>.
Available hardware breakpoints often prove to be insufficient. Then the debugger can use unlimited software breakpoints to work around this limitation.
|
Setting a Software Breakpoint means modifying flash memory. Editing flash memory during debug session is disabled on some devices. In this case software breakpoints won't work. |
When using software execution breakpoints, winIDEA will change the object code on the target address and replace it with a special instruction, which stops the CPU execution. Once the breakpoint is hit and you wish to continue the execution, the code is switched to its original state, the instruction is stepped over and the code is again replaced with the breakpoint instruction. While all this is done in the background, you should be aware that:
•Microcontroller memory is being manipulated each time you interact with the breakpoint, which can amount to a significant number of memory writes. This can put a serious stress on the microcontroller memory, specially internal FLASH which usually has a limited number of guaranteed write cycles.
•When using software execution breakpoints on an application loaded in FLASH memory, you will notice delays when interacting with these breakpoints. Each time a breakpoint is interacted with, a whole sector of the FLASH memory needs to be erased, modified and programmed back, which takes time. You can speed this up somewhat by enabling Hardware / CPU Options / Debugging / Set/Clear SW BPs before Run, which means that if you set several successive breakpoints, each FLASH sector will be programmed only once (when the CPU is set to run) instead of once for every breakpoint.
•Debugger, when executing source step or run until debug command uses one breakpoint. Hence when all available hardware breakpoints are used as execution breakpoints the debugger may fail to execute the debug step. The debugger offers Reserve one breakpoint for high-level debugging option in the Debug / Debug Options / Debugging page to circumvent this. By default this option is checked and you can uncheck it anytime.
More resources
•Breakpoints - Video Tutorial
•Breakpoint bisecting - Video Tutorial
•Breakpoints plugin - Offers an enhanced view for faster manipulation of all the breakpoints in the project
•Breakpoint Wizard - Allows you to configure the hardware breakpoint either as execution breakpoint or access breakpoint
