STM32 在 Keil 環境下如何使用 Cm_Backtrace進行錯誤追蹤
引言
我們在平常使用STM32單片機的時候，往往會碰到程序跑飛的情況，出現hard_fulat等錯誤，而我們在定位錯誤的時候，采用的方法往往是連上仿真器，一步一步單步調試，定位到具體的錯誤代碼，再去猜測、排除、推敲錯誤原因，這樣一個過程很是痛苦，而且在實際情況中，很多產品真機調試時必須斷開仿真器或者說，問題確實存在，但是極難出現，所以在基于這樣一個問題背景下，RTT 的大佬armink開發了一個基于 ARM Cortex-M系列的 MCU錯誤追蹤庫，用于幫助開發者解決上述問題。
CmBacktrace 的作用及適用平臺首先，CmBacktrace 是一款針對于 ARM Cortex-M 系列 MCU 的錯誤代碼自動追蹤、定位、錯誤原因自動分析的開源庫，它所支持的錯誤包括：
- 斷言(assert)
- 故障
- Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, Debug Fault
支持裸機以及以下操作系統平臺：
- RT-Thread
- UCOS
- FreeRTOS
適配 Cortex-M0/M3/M7 MCU，支持IAR、KEIL、GCC編譯器，能夠達到的效果是：故障原因自動診斷，自動分析故障原因，定位發生故障代碼位置，輸出錯誤現場的函數調用棧。
移植
當前筆者所使用的平臺是 keil 5,所使用的控制器是 STM32F103,我們準備一個具備串口功能的工程，工程結構如下所示：
image-20210306101326283
緊接著，我們來看下 cm_backtrace的源代碼：
image-20210306101659128
上述中，cm_backtrace文件夾中存放的是源代碼，我們需要將其全部復制到我們的工程目錄，demos是使用的例子，里面分為有操作系統和無操作系統兩種類型，然后tools存放的是工具，用命令行的形式來分析代碼錯誤的工具,將相關文件復制到工程目錄之后工程目錄下的文件如下所示：
image-20210306102410525
然后，我們將相關文件添加至工程中，下面是添加之后的工程文件：
image-20210306102815766
同時應該添加相關頭文件路徑，添加的頭文件路徑如下所示：
image-20210306102919999
至此，cm_backtrace的源代碼就添加完了，我們來編譯一下。編譯結果如下所示：
image-20210306103031890
可以發現有很多錯誤，這是因為我們的相關宏還沒有打開，我們以照源碼中的說明文檔中的一個表，在 cmb_def.h中依次打開對應的宏，表如下所示：
| 配置名稱 | 功能 | 備注 |
|---|---|---|
| cmb_println(…) | 錯誤及診斷信息輸出 | 必須配置 |
| CMB_USING_BARE_METAL_PLATFORM | 是否使用在裸機平臺 | 使用則定義該宏 |
| CMB_USING_OS_PLATFORM | 是否使用在操作系統平臺 | 操作系統與裸機必須二選一 |
| CMB_OS_PLATFORM_TYPE | 操作系統平臺 | RTT/UCOSII/UCOSIII/FREERTOS |
| CMB_CPU_PLATFORM_TYPE | CPU平臺 | M0/M3/M4/M7 |
| CMB_USING_DUMP_STACK_INFO | 是否使用 Dump 堆棧的功能 | 使用則定義該宏 |
| CMB_PRINT_LANGUAGE | 輸出信息時的語言 | CHINESE/ENGLISH |
更改之后的代碼如下所示：
image-20210306103649154
更改了宏之后，我們再來編譯代碼，編譯結果如下所示：
image-20210306103729814
提示要開啟c99編譯模式，我們在keil中設置，設置方式如下所示：
image-20210306103831859
繼續編譯，看到還有一個錯誤信息，編譯結果如下所示：
image-20210306104005145
這是因為cmb_fault.S中使用匯編定義了 HardFault_Handler函數，而在原本工程中，stm32f10x_it.c中已經定義了 HardFault_Handler，我們將stm32f10x_it.c中的HardFault_Handler注釋掉，代碼如下所示：
image-20210306104326301
現在編譯就可以通過了。
測試
移植完之后，我們現在來測試一下，在單片機中除0造成的錯誤如何檢查出來，我們在主函數中添加如下所示的代碼：
- #include "stm32f10x.h"
- #include "bsp_usart.h"
- #include <cm_backtrace.h>
- #define HARDWARE_VERSION "V1.0.0"
- #define SOFTWARE_VERSION "V0.1.0"
- extern void fault_test_by_div0(void);
- /**
- * @brief 主函數
- * @param 無
- * @retval 無
- */
- int main(void)
- {
- /*初始化USART 配置模式為 115200 8-N-1，中斷接收*/
- USART_Config();
- /* CmBacktrace initialize */
- cm_backtrace_init("CmBacktrace", HARDWARE_VERSION, SOFTWARE_VERSION);
- fault_test_by_div0();
- while(1)
- {
- }
- }
將程序燒錄單片機，通過串口調試助手觀查輸出的信息：
image-20210306105316179
我們可以看到輸出信息顯示了當前用法錯誤是：企圖除 0 操作，并給出了相關寄存器信息，但是我們還不知道出現錯誤的代碼在哪一行，這個時候，就需要使用到前文所說的tools文件夾下的工具，addr2line工具。在使用這個工具的時候，需要知道當前工具輸出的可執行文件的名字，我們打開keil,信息如下所示：
image-20210306105719377
然后，我們找到 cm_backtrace文件夾下的tools工具，將其復制到USART.axf所在的目錄，復制之后的文件夾目錄如下所示：
image-20210306110017993
在當前文件夾下打開 cmd窗口，然后運行addr2line -e USART.axf -a -f 08001844 0800189a,在這里提一下打開 cmd的方法，按住Shift鍵，然后右鍵，打開Powershell
image-20210306110527928
打開的 Powershell如下所示，并在Powershell中輸入start cmd打開cmd窗口，然后在cmd窗口輸入addr2line -e USART.axf -a -f 08001844 0800189a,結果如下所示：
image-20210306110839097
可以看到錯誤信息是fault_test.c的38行，我們打開源代碼查看：
image-20210306111229605
可以看到確實是38行，問題分析正確。
小結
這就是本期分享的所有內容了，工欲善其事，必先利其器這話還是很有道理，學會使用各種分析工具也能夠加快我們的開發進度，幫助我們更快更好地解決問題。
