Software/hardware breakpoint for Embedded ARM Simulators

Breakpoint can be divided into two categories: hardware breakpoint and software breakpoint:

1. hardware breakpoint requires hardware support for the target CPU. Currently, the popular internal hardware design of/9 provides two sets of registers for storing breakpoint information. Therefore, the/9 kernel supports up to two hardware breakpoints, arm11 supports eight hardware breakpoints. this is irrelevant to the debugger.

2. software breakpoint is implemented by setting feature values in the code. when you need to set a software breakpoint at an address code, the simulator will first back up the code to protect it, write the preset breakpoint feature value (usually 0x0000 or other values that are not easy to be confused with the Code) to this address to overwrite the original code data. when the program runs to the address where the feature value is located, the simulator identifies that this is a soft breakpoint, which will interrupt. when the breakpoint is canceled, the previously protected code information is automatically restored.

 
The hardware breakpoint can be set to any position in the code, including ROM and ram. The software breakpoint can only be set to ram because the value of the corresponding address needs to be modified. due to the flexibility of hardware breakpoint settings, it is the most preferred breakpoint resource. However, it is difficult for engineers to perform in-depth debugging on two breakpoints, therefore, software breakpoints can be used as supplemental resources for hardware breakpoints.

Generally, software breakpoints can only be set on the code run by Ram. As the amount of code in the system increases, especially in the mobile communication field, the expansion of large-capacity Ram will inevitably increase the product cost, so now many systems run code directly on flashrom. for a system that runs code on Flash ROM, the general software breakpoint cannot be set, which is also the limitation of the software breakpoint. for such a system, only two hardware breakpoints can be used alternately to meet the requirements, but this may cause some inconvenience.

To solve this problem well, only by enabling the simulator to set software breakpoints on Flash ROM, can the breakpoint resources available in the simulator be expanded.
The principle of setting a software breakpoint on flashrom is similar to setting a soft breakpoint on Ram. It also replaces the original code with a pattern at the set breakpoint, so that the breakpoint event occurs by recognizing the pattern. the difference is that you need to erase the flash when setting the software breakpoint on Flash ROM. This requires the simulator to have the flash programming function and write the signature within the shortest time. after completing this series of read/write operations, engineers who debug code on flashrom can obtain more breakpoint resources, which greatly improves the development efficiency.
However, it takes some time to erase and write the flash, so there will be a pause when the flash breakpoint is executed. although this is a little worse than the software breakpoint on Ram, it is completely acceptable for engineers to facilitate the debugging work as a whole.

Setting breakpoints for debugging is the most basic debugging method. Selecting an ice simulator with abundant breakpoint resources can significantly improve the debugging efficiency. of course, the premise is that engineers can use various breakpoint resources flexibly.
Go to Tony embedded Forum, http://www.cevx.com/bbs/thread-24600-1-1.html