In the process of developing embedded applications, debugging is needed to solve problems that arise during program operation. Depending on whether the "full-speed running state" of the program will be interrupted, debugging methods can be divided into intrusive debugging and non-intrusive debugging.
The intrusive debugging methods are as follows:
Halt and single-step program execution
Hardware breakpoints and breakpoint instructions (BKPT)
Variable data observation point (Watch window)
Access register values
Debug monitor exception
Non-intrusive debugging methods are as follows:
Accessing memory while the kernel is running
Instruction tracing, which requires hardware to include an instruction trace unit (ETM)
Normally, we use intrusive debugging, but this debugging will break the full-speed running state of the program. Non-intrusive debugging can understand the running status of the program while ensuring that the program runs at full speed. When debugging large software and RTOS multi-tasking systems, or applications related to communication timing (non-intrusive debugging will break the communication timing), the application code may suddenly run away or generate abnormal interrupts, and the cause of the problem may be difficult to find.
At this time, non-intrusive debugging functions such as instruction tracing play an incomparable role. Instruction tracing can record the instruction execution history inside the MCU before the problem occurs. This information can help developers trace back to the problem site to accurately locate the cause of the problem.