Debugging Synergy Applications: Efficient Debugging using Breakpoints

The first line of defense used by embedded systems developers when debugging their software is to use breakpoints. Every developer knows how to create a breakpoint and step through code, but in many cases, developers don’t realize what’s happening behind scenes or that there may be more efficient methods available to them. In this post, we will examine how to use and manage breakpoints in the Renesas Synergy™ Tools environment using e2 Studio.

Breakpoints allow a developer to pause application execution on any line of code or even on a specific instruction that will be executed by the microcontroller. Breakpoints are an invasive debugging technique because they break the real-time performance of the system and allow developers to poke and prod memory in a way that could change the way the application executes its program. There are three primary breakpoint types that a developer may encounter:

  • Hardware breakpoints
  • Software breakpoints
  • Flash breakpoints

Hardware breakpoints use the microcontrollers flash patch module with comparators to match the PC counter to a predetermine address. When the match occurs, the application stops executing its code. There are typically only two to four hardware breakpoints available in an ARM Cortex-M processor. Once those breakpoints are used, a developer can use software breakpoints.

Software breakpoints insert either a special instruction such as halt or raise an exception that the debugger then breaks the code execution. Once the developer presses continue, the halt is removed and the original instruction is reinserted and executed.

Finally, flash breakpoints are special breakpoints used by the debugger that stores the PC value in flash and when that value is detected, the debugger halts the program. A developer who has a debugger with unlimited flash breakpoints can have nearly unlimited breakpoints in their application.

A developer who is debugging their application can used advanced breakpoints to more efficiently debug their software. For example, if a developer had a for loop that was going to be iterated through but they were interested in one of the later iterations, there is no need to set a breakpoint and then single step through the code until the count is reached. A developer creates a breakpoint and then right clicks on it, selecting Breakpoint Properties for advanced options as shown below:

The Breakpoint Properties allows a developer to specify several advanced behaviors that are not available by simply double clicking. Under the common properties, a developer can select the breakpoint type that they want to use. Hardware breakpoints are faster than software breakpoints, so a developer should prefer hardware breakpoints until there are no more available. A developer can also specify a conditional statement such as i==1. In this case, the breakpoint will not trigger if i is any value other than 1. Complex conditionals using multiple variables can be created so that the breakpoint occurs only under specific conditions in the application. For a simple loop, a developer could also just specify how many times the breakpoint should be ignored before it breaks execution.

The Breakpoint Properties also contains an Actions option. In the Actions parameters, a developer can select additional actions that should occur when the breakpoint is reached. For example, a developer could choose that a specific text statement be entered in the log. This would be done by clicking Actions, new and then selecting Log Action from the dropdown. A developer could then enter the desired text as shown below:


There are several different actions that can be taken such as:

  • Play a sound
  • Log action
  • Resume action
  • External Tool action
  • Reverse Debug action

Once an action has been created, it can be attached to that specific breakpoint by clicking attach. The result would look something like the following:


Clicking okay and running the application would result in the application running until it reached the breakpoint and break execution when the variable i became one. When the breakpoint is reached, the action is also taken which prints in the log that the breakpoint was reached as shown below:


Managing breakpoints in an application can also be done very easily by examining the breakpoint tab. The breakpoint tab displays not just the breakpoints that are active but also provides useful information about those breakpoints. For example, a developer can determine:

  • If the breakpoint is active
  • Can enable or disable it
  • View the breakpoint type: hardware, software, etc
  • Any condition that is specified for the breakpoint to occur.

A develop can even globally enable or disable breakpoints.


Breakpoints are the defacto tool developers use to debug their applications. To do so efficiently, developers need to master advanced breakpoint capabilities and understand how they can easily manage those breakpoints once they are created. After all, we don’t want to spend precious time stepping through code we aren’t interested in or having to continually create and delete breakpoints that are interesting to us throughout the whole development cycle.

Until next time,

Live long and profit!



Hot Tip of the Week

If you are interested in seeing some advanced debugging techniques in action check out the Renesas Presents Youtube channel. You will find a video demonstrating some advanced debugging techniques using e2 studio.

A basic debugging techniques video is available too: