CmBacktrace

CmBacktrace: ARM Cortex-M series MCU error tracking library

中文页 | English

0、What is CmBacktrace

CmBacktrace (Cortex Microcontroller Backtrace) is an open source library that automatically tracks and locates error codes for ARM Cortex-M series MCUs, and automatically analyzes the causes of errors. The main features are as follows:

• Supported errors include:
  • Assert
  • Fault (Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, Debug Fault)
• Failure reason Automatic diagnosis: When a failure occurs, the cause of the failure can be automatically analyzed, and the code location of the failure can be located, without the need to manually analyze the complicated fault registers; -Output the function call stack of the error site (need to cooperate with the addr2line tool for precise positioning), restore the field information when the error occurred, and locate the problem code location and logic more quickly and accurately. You can also use the library under normal conditions to get the current function call stack;
• Support bare metal and the following operating system platforms:
  • RT-Thread
  • UCOS
  • FreeRTOS (source code needs to be modified)
• According to the error scene status, output the corresponding thread stack or C main stack;
• The fault diagnosis information supports multiple languages ​​(currently: Simplified Chinese, English);
• Adapt to Cortex-M0/M3/M4/M7 MCU;
• Support IAR, KEIL, GCC compiler;

1. Why choose CmBacktrace

Beginner Newcomer: For newcomers who switch from simple microcontrollers such as C51 and MSP430 to more complex ARM, the chance of "hard falut" death from time to time makes newcomers instantly stunned. The method of locating errors is often to connect to the emulator, step by step F10/F11, locate the specific error code, and then guess, eliminate, and deliberate on the cause of the error. This process is very painful.

Skilled veteran: Slowly everyone knows that the fault cause and fault code address can be located through the fault register information. Although this can solve a small part of the problem, the repeated and tedious analysis process will also delay a lot of time. Moreover, for some complex problems, it is impossible to solve only by the code address, and the function call logic relationship of the wrong scene must be restored. Although the function call stack can be viewed by connecting to the emulator, it cannot be displayed in the fault state, so it is necessary to step by step F10/F11 to locate the error code. In addition, there are two scenarios,

1. The emulator must be disconnected when debugging many products
2. The problem does exist, but it is extremely difficult to reproduce

So locating such problems is even more difficult.

Use this library: All the above problems can be solved easily. The error message can be output to the console, and the error message can also be saved using the Log function of EasyFlash In Flash, the last error message can still be read after the device crashes and restarts. The information output by CmBacktrace includes function call stack, fault diagnosis result, stack, fault register and product firmware information, which greatly improves the efficiency and accuracy of error location.

As the saying goes, a worker must first sharpen his tools if he wants to do his job well. So sometimes the reason for the low efficiency may be that you will use too few types of tools.

Cooperation, Contribution: The development of open source software is inseparable from everyone's support. You are welcome to make more suggestions and hope that more people will join in and improve together. If you think this open source project is great, you can click Project Homepage (Github|OSChina|Coding) Star** in the upper right corner, At the same time recommend it to more friends in need.

2. How to use CmBacktrace

2.1 Demo

The demonstration is divided into the following steps:

1. Manufacturing division by zero exception (IAR project, click to view source code)
2. View error diagnosis information
3. View the basic information of the function call stack
4. Enter the path where the executable file is stored in the project project through the command line tool
5. Use the addr2line command to view the function call stack details and locate the error code

2.2 Demo

2.3 Porting instructions

2.3.1 Preparation

1. Check whether there is a suitable Demo in the \demos directory, if there is a similar, it is recommended to modify it on the basis of it
2. Identify the operating system/bare metal platform and CPU platform
3. Add all source files under \src to the product project, and ensure that the source code directory is added to the header file path
4. The cmb_fault.s assembly file (click to view) can be optionally added to the project. After adding, you need to add the original project HardFault_Handler comment out
5. Put the cm_backtrace_init function in the project initialization place for execution
6. Put cm_backtrace_assert in the assertion function of the project for execution. For specific usage, please refer to the API description below
7. If the cmb_fault.s assembly file is not enabled in step 4, you need to put cm_backtrace_fault in the fault handling function (for example: HardFault_Handler) for execution. For details, refer to the API description below

2.3.2 Configuration Instructions

Configuration file name: cmb_cfg.h, users need to manually configure themselves for different platforms and scenarios. Common configurations are as follows:

Note: The content of the above configuration can be selected in cmb_def.h, please read the source code for more flexible configuration

2.4 API description

2.4.1 Library initialization

void cm_backtrace_init(const char *firmware_name, const char *hardware_ver, const char *software_ver)

Note: The above input parameters will be output in case of assertion or failure, mainly for retrospective purposes

2.4.2 Get function call stack

size_t cm_backtrace_call_stack(uint32_t *buffer, size_t size, uint32_t sp)

Example:

…

2.4.3 Tracking assertion error messages

void cm_backtrace_assert(uint32_t sp)

Note: The input parameter SP should be obtained inside the assertion function as much as possible, and as close as possible to the beginning of the assertion function. When used in the sub-function of the assertion function (for example: in the assertion hook method of RT-Thread), due to the nesting of the function, there will be the operation of registering the stack, and the SP will be changed at this time, and manual adjustment is required ( Add and subtract a fixed deviation value) into the parameter value, so as a novice, it is not recommended to use this function in the sub-function of the assertion.

2.4.4 Tracking fault information

void cm_backtrace_fault(uint32_t fault_handler_lr, uint32_t fault_handler_sp)

This function can be called in the fault handling function (for example: HardFault_Handler). In addition, the library itself provides assembly files processed by HardFault (click to view, you need to choose according to your own compiler), The cm_backtrace_fault method is automatically called in the event of a fault. So when transplanting, the easiest way is to use the assembly file directly.

2.5 FAQ

2.5.1 Compilation error, suggesting that C99 support is required

Click to view the tutorial: Open Keil/IAR/GCC C99 support in one step

2.5.2 How to view the specific name and code line number of the function in the function call stack

Click to view the tutorial: How to use the addr2line tool to get the function call stack details

2.5.3 Fault handling function: HardFault_Handler repeated definition

When the cmb_fault.s assembly file provided by this library is used, because HardFault_Handler is already defined in the assembly file, if this function is defined elsewhere in the project, an error that HardFault_Handler is repeatedly defined will be prompted. There are two solutions at this time:

1. Comment/delete the HardFault_Handler function defined in other files, and only keep the cmb_fault.s;
2. Remove cmb_fault.s from the project, and manually add the cm_backtrace_fault function to the existing fault handling function, but it should be noted that you must ** ensure the readiness of the function to enter the parameters**, otherwise it may cause The fault diagnosis function and stack printing function cannot operate normally. So if you are a novice, the second solution is not recommended.

2.5.4 Prompt that the main stack information cannot be obtained during initialization

The default main stack configuration is defined in cmd_def.h, roughly as follows:

…

For example, under the Keil-MDK compiler, STACK will be selected as the name of the main stack block by default, but under some special platforms, the name of the main stack block of the project may not be called `ST