對于從C51 、MSP430 等簡單單片機轉而使用更加復雜的 ARM 新人來說，時不時出現的"hard falut"死機會讓新人瞬間懵掉。定位錯誤的方法也往往是連接上仿真器，一步步 F10/F11單步，定位到具體的錯誤代碼，再去猜測、排除、推敲錯誤原因，這種過程十分痛苦，且花費的時間很長。

當然，也有部分開發者通過故障寄存器信息來定位故障原因及故障代碼地址，雖然這樣能解決一小部分問題，但是重復的、繁瑣的分析過程也會耽誤很多時間。而且對于一些復雜問題，只依靠代碼地址是無法解決的，必須得還原錯誤現場的函數調用邏輯關系。雖然連接仿真器可以查看到的函數調用棧，但故障狀態下是無法顯示的，所以還是得一步步F10/F11單步去定位錯誤代碼的位置。另外，很多產品真機調試時必須斷開仿真器，這又使定位錯誤代碼雪上加霜。

為了能讓開發者更快的知道造成hard falut 的原因，更快的定位到錯誤代碼的位置，本應用筆記將一步步介紹CmBacktrace 的相關知識和使用方法，讓開發者能不費吹灰之力就找出代碼中的問題所在。

本文的結構

本文首先介紹了什么是 CmBacktrace，然后介紹了使用 CmBacktrace 要做的準備工作，接著介紹了在RT-Thread中使用CmBacktrace的例子，最后總結了使用 CmBacktrace 時的常見問題。通過這些講解，希望開發者能更快上手 CmBacktrace。

CmBacktrace 是什么

CmBacktrace（Cortex Microcontroller Backtrace）是一款針對 ARM Cortex-M 系列 MCU 的錯誤代碼自動追蹤、定位，錯誤原因自動分析的開源庫。

主要特性如下：

支持的錯誤包括：

斷言（assert）

故障（Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, Debug Fault）

故障原因自動診斷：可在故障發生時，自動分析出故障的原因，定位發生故障的代碼位置，而無需再手動分析繁雜的故障寄存器；

輸出錯誤現場的函數調用棧（需配合 addr2line 工具進行精確定位），還原發生錯誤時的現場信息，定位問題代碼位置、邏輯更加快捷、精準。也可以在正常狀態下使用該庫，獲取當前的函數調用棧；

支持 裸機 及以下操作系統平臺：

RT-Thread

UCOS

FreeRTOS（需修改源碼）

根據錯誤現場狀態，輸出對應的 線程棧 或 C 主棧；

故障診斷信息支持多國語言（目前：簡體中文、英文）；

適配 Cortex-M0/M3/M4/M7 MCU；

支持 IAR、KEIL、GCC 編譯器；

準備工作

準備 addr2line

在 https://github.com/armink/CmBacktrace/tree/master/tools/addr2line 頁面中下載 addr2line（需要按照自己的系統版本下載），然后將下載下來的addr2line 拷貝至C:\Windows下 ，這樣就可以使用 addr2line 了。

ENV配置

RT-Thread 已經對 CmBacktrace 做了適配，直接在 ENV 使能 CmBacktrace 就可以使用了。

下面介紹如何在 ENV 中配置CmBacktrace：

打開 ENV，進入相應的 bsp 目錄

輸入 menuconfig

進入 RT-Thread online packages -> tools packages

使能 CmBacktrace

進入 CmBacktrace 配置界面

選擇自己的 CPU 平臺

選擇打印的語言

選擇版本，推薦使用最新版

確認宏定義

CmBacktrace 的運行需要知道存放代碼的 SECTION 的開始地址和結束地址以及棧的 SECTION 的開始地址和結束地址。用戶只需要查看 cmb_def.h 文件里默認定義的 CMB_CSTACK_BLOCK_NAME 和 CMB_CODE_SECTION_NAME 這兩個宏是否正確即可。如不正確，用戶需要根據分散加載文件和啟動文件來確定這兩個宏的值并在 cmb_cfg.h 里重新定義這兩個宏。

這里以 rt1052 的 mdk 工程為例進行講解如何在工程里找到這兩個宏的值。首先找 CMB_CSTACK_BLOCK_NAME 的值，我們打開工程里的啟動文件，可以在文件的開頭看到這樣一段代碼

AREA RESET, DATA, READONLY EXPORT __Vectors EXPORT __Vectors_End EXPORT __Vectors_Size IMPORT |Image$$ARM_LIB_STACK$$ZI$$Limit| __Vectors DCD |Image$$ARM_LIB_STACK$$ZI$$Limit| ; Top of Stack

Image\$\$ARM_LIB_STACK\$\$ZI\$\$Limit 就是我們要找的內容了，因為代碼里會自動拼接上最后的 $$Limit，所以 CMB_CSTACK_BLOCK_NAME 的值應該是 Image\$\$ARM_LIB_STACK\$\$ZI。

CMB_CODE_SECTION_NAME 的值在分散加載文件里尋找，分散加載文件可以點擊 MDK的 Options -> Linker 選項面板里的 Edit... 按紐打開

我們可以找到這樣一段代碼

ER_IROM1 m_text_start m_text_size ; load address = execution address { * (RESET,+FIRST) * (InRoot$$Sections) .ANY (+RO) }

保存有 .ANY (+RO) 的 SECTION 名字就是我們要找的值，所以，CMB_CODE_SECTION_NAME 的值為 ER_IROM1。

開啟C99

CmBacktrace 的使用需要 C99 的支持，使用 MDK 的開發者可以在 Options -> C/C++面板中勾選 C99 Mode選項。

使用IAR的開發者，可以在 Options -> C/C++ Compiler 中選擇 C99。

使用 GCC 進行編譯的用戶，在編譯配置中增加-std=c99即可 。

確定初始化參數

在使用 CmBacktrace 之前需要先調用下初始化函數，函數原型如下：

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

CmBacktrace 的初始化函數需要 3 個參數，第一個參數是固件名字，第二個參數是硬件版本，第三個參數是軟件版本。這三個參數會在發生 hard fault時打印出來，firmware_name需要填寫生成的固件名稱，錯誤填寫會導致在使用 addr2line 時無法找到文件。hardware_ver和software_ver建議填寫真實的軟硬件版本號，方便后期調試和維護。在 cmb_port.c 文件中，我們可以看到 RT-Thread 已經將 rt_cm_backtrace_init 函數進行了自動初始化，默認的三個參數分別是rtthread,1.0,1.0，開發者需要按照實際情況進行更改。

使用示例

CmBacktrace 提供了一個測試函數，提供除零測試和執行非對齊訪問的測試。當做完上面的準備工作后，開發者可以直接將工程編譯，下載進板子里，進行測試，判斷 CmBacktrace 是否正常工作。

CmBacktrace 導出到 finsh shell 中的測試函數命令為cmb_test，輸入 cmb_test DIVBYZERO 就是進行除零測試，輸入 cmb_test UNALIGNED 就是執行非對齊訪問的測試。

我們看下運行完除零測試的結果

msh />cmb_test DIVBYZERO thread pri status sp stack size max used left tick error -------- --- ------- ---------- ---------- ------ ---------- --- tshell 20 ready 0x00000100 0x00001000 23% 0x00000009 000 phy 30 suspend 0x0000006c 0x00000200 30% 0x00000001 000 tcpip 10 suspend 0x000000b4 0x00000800 17% 0x00000014 000 etx 12 suspend 0x00000088 0x00000400 13% 0x00000010 000 erx 12 suspend 0x00000088 0x00000400 13% 0x00000010 000 mmcsd_de 22 suspend 0x00000090 0x00000400 49% 0x00000013 000 tidle 31 ready 0x00000054 0x00000100 32% 0x00000018 000 main 10 suspend 0x00000064 0x00000800 35% 0x00000012 000 Firmware name: rtthread-imxrt, hardware version: 1.0, software version: 1.0 Fault on thread tshell ===== Thread stack information ===== addr: 80002ad0 data: 00000012 addr: 80002ad4 data: 6002ae58 addr: 80002ad8 data: 80001a40 addr: 80002adc data: 6000b575 addr: 80002ae0 data: 80001a40 addr: 80002ae4 data: 80001a49 addr: 80002ae8 data: 00000000 addr: 80002aec data: 00000000 addr: 80002af0 data: 00000000 addr: 80002af4 data: 00000000 addr: 80002af8 data: 00000000 addr: 80002afc data: 00000000 addr: 80002b00 data: 00000000 addr: 80002b04 data: 00000000 addr: 80002b08 data: 20000c7c addr: 80002b0c data: 00000012 addr: 80002b10 data: 80001a40 addr: 80002b14 data: 20000c7c addr: 80002b18 data: 00000001 addr: 80002b1c data: deadbeef addr: 80002b20 data: deadbeef addr: 80002b24 data: deadbeef addr: 80002b28 data: deadbeef addr: 80002b2c data: 60019ffb addr: 80002b30 data: 00000001 addr: 80002b34 data: 0000000d addr: 80002b38 data: 00000000 addr: 80002b3c data: 60015a7b addr: 80002b40 data: 23232323 ==================================== =================== Registers information ==================== R0 : 0000000a R1 : 00000000 R2 : 0000004f R3 : 80808000 R12: 01010101 LR : 6000c5ad PC : 6000c5c8 PSR: 41000000 ============================================================== Usage fault is caused by Indicates a divide by zero has taken place (can be set only if DIV_0_TRP is set) Show more call stack info by run: addr2line -e rtthread-imxrt.axf -a -f 6000c5c8 6000c5a9 6002ae54 6000b571 60019ff7 60015a77

CmBacktrace 首先打印出了發生 hard falut 時的所有線程信息，接著打印了固件名字和軟硬件版本號，再打印了錯誤是發生在 tshell 這個線程里面的（因為我們是在 tshell 這個線程里調用的除零測試函數），緊接著打印的是線程的棧信息和寄存器信息。最后兩行信息是最重要的，倒數第二行介紹了發生故障的原因，是因為除零造成的。最后一行提示如果需要獲取函數調用棧，需要在 addr2line 中運行 CmBacktrace 給出的參數。

在使用addr2line 之前我們要先確認保存了工程對象文件的文件夾位置。使用mdk的開發者，可以在 Options -> Output 面板中查看，設置對象文件的保存路徑

使用IAR的開發者，可以在 Options -> General Options 面板的Output選項中查看和設置。

我們將 run：后面的所有內容都復制下來，然后進入保存了工程生成的對象文件的文件夾，打開env，將剛剛復制的內容粘貼上去，按下回車，錯誤現場的函數調用棧就會輸出出來，我們看下剛剛進行除零測試時的函數調用棧的信息

> addr2line -e rtthread-imxrt.axf -a -f 6000c5c8 6000c5a9 6002ae54 6000b571 60019ff7 60015a77 0x6000c5c8 cmb_test D:\rt-thread\bsp\imxrt1052-evk/packages\CmBacktrace-v1.2.0\/cmb_port.c:87 0x6000c5a9 cmb_test D:\rt-thread\bsp\imxrt1052-evk/packages\CmBacktrace-v1.2.0\/cmb_port.c:82 0x6002ae54 FSymTab$$Base ??:? 0x6000b571 msh_get_cmd D:\rt-thread\bsp\imxrt1052-evk/..\..\components\finsh\/msh.c:312 0x60019ff7 msh_exec D:\rt-thread\bsp\imxrt1052-evk/..\..\components\finsh\/msh.c:335 0x60015a77 finsh_thread_entry D:\rt-thread\bsp\imxrt1052-evk/..\..\components\finsh\/shell.c:613

我們可以看到，CmBacktrace 不僅僅定位出了是 cmb_port.c里第87行產生的問題，還打印出了函數調用邏輯關系，方便開發者進行 BUG 修復。

常見問題

使用前必須確認自己的 MCU 是 ARM Cortex-M0(+)/M3/M4/M7 架構，其他架構暫不支持。

使用前要確定 CMBCSTACKBLOCKNAME 和 CMBCODESECTIONNAME 兩個宏的宏定義，如果定義錯誤，CmBacktrace會無法正確使用。

初始化時要輸入正確的固件名稱，不然使用 addr2line 時會提示找不到文件

當線程的棧被寫穿時，CmBacktrace 無法正常使用。