In the process of developing embedded applications, although good programming practices and appropriate coding standard detection software can reduce the number of errors in the code writing stage, it is still inevitable that some errors will only be triggered during the program running process. In order to solve the problems during the program running process, it is necessary to use a debugger to observe the execution of the code and the changes in the software status.
In the process of program debugging, the importance of breakpoints is self-evident. In the debugging state, when the program encounters a breakpoint, it will stop executing and hand over control to the debugging software. The debugger can display the current application status, including the values of variables and registers, memory and stack usage, and the function call relationship of the application reaching the breakpoint location. This information can help developers analyze whether the execution status of the program meets expectations and help determine the cause of the error when a problem occurs.
(1) Debugging in the RAM area
During the development process, the application can be downloaded to RAM for running and debugging. The debugger only needs to use simple breakpoint instructions, and RAM allows multiple reads and writes. The breakpoint instructions in the RAM area will not have a significant impact on program execution. However, the limitation of this method is that the RAM space of the MCU is usually small, and when the application is large, it cannot be debugged in RAM.
(2) Debugging in the Flash area
Unlike RAM, Flash storage space is usually larger. When debugging in RAM is not possible, debugging can only be performed in the Flash area. Microcontroller designers provide hardware breakpoints for use when debugging in the Flash area. Hardware breakpoints compare the PC pointer with the breakpoint position and check whether the instruction is called. When the instruction at the breakpoint is called, the program will stop and start the debugger. The number of hardware breakpoints is determined by the core used by the chip. There are only 2 hardware breakpoints in the ARM7 and ARM9 cores, and 4-6 available hardware breakpoints in the Cortex-M3 and M4 cores. During the debugging process, when the number of hardware breakpoints is used up, new breakpoints cannot be added. New breakpoints can only be added after canceling the previously added breakpoints, which will undoubtedly seriously affect the efficiency of program development.
(3) External Flash storage chip debugging
When the complexity of the developed application increases further, the external Flash storage may be used. How to debug the application at this time? In most microcontrollers using the Cortex-M core, the address range in which the hardware breakpoints provided inside the chip can take effect during the debugging process is limited. When using the external Flash, the built-in hardware breakpoints will not take effect within the address range of the external Flash storage. At this time, it will be impossible to set breakpoints in these areas to debug the application.
When using external Flash storage based on address mapping extension, the unlimited Flash breakpoint function supported by Segger J-Link products can help us add breakpoints and debug the off-chip Flash.
Segger unlimited Flash breakpoint function
J-Link supports a debugging feature called "Unlimited Flash Breakpoints". "Unlimited Flash Breakpoints" allows the user to set an unlimited number of breakpoints when debugging in Flash. Without this feature, the number of breakpoints that can be set in Flash is limited to the number of hardware breakpoints supported by the CPU debug unit.
J-Link's "Unlimited Flash Breakpoints" applies to both on-chip and external Flash, including QSPI Flash added via memory mapping.
How to implement unlimited Flash breakpoints
Segger J-Link series products use a mix of hardware and software breakpoints to minimize the impact on Flash when implementing the unlimited Flash breakpoint function. When the number of hardware breakpoints is exhausted and new breakpoints are added, the Segger software will reprogram the Flash block where the breakpoint is located to add the breakpoint.
Although Flash has a certain limit on the number of writes, Segger has made a lot of targeted optimizations to reduce the impact on Flash when implementing this function. For example, for multiple breakpoints in the same block, Segger will add multiple breakpoints by reprogramming the Flash block once. Segger will reprogram the Flash block only when necessary, and some operations will be completed through the built-in instruction set simulator, so as to minimize the impact on Flash memory.
Segger's unlimited Flash breakpoint debugging function removes the limitation of hardware breakpoints on program debugging, which can improve the development efficiency of developers. For the situation where the Cortex-M core chip adds external Flash, the unlimited Flash breakpoint function may be the only external Flash debugging solution.
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
