怎样去开发一个基于ARM Cortex-M的MCU错误追踪库呢

问答对人有帮助，内容完整，我也想知道答案 0 为什么使用STM32 单片机时程序会经常跑飞呢？怎样去开发一个基于ARM Cortex-M的MCU错误追踪库呢？ 0
2021-11-26 07:41:09　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × heks 该类别下有 50 个回答。邀请回答 hgimtk 该类别下有 44 个回答。邀请回答新星之火12138 该类别下有 42 个回答。邀请回答 wang21cj 该类别下有 41 个回答。邀请回答 chm5 该类别下有 40 个回答。邀请回答 hjfjsdgfjdsf 该类别下有 37 个回答。邀请回答 fdjslkjd 该类别下有 35 个回答。邀请回答 uvysdfydad 该类别下有 35 个回答。邀请回答 werywer 该类别下有 35 个回答。邀请回答 h1654155957.9520 该类别下有 35 个回答。邀请回答 jenny042 该类别下有 34 个回答。邀请回答 dfzvzs 该类别下有 34 个回答。邀请回答维生素B2 该类别下有 34 个回答。邀请回答凤毛麟角该类别下有 34 个回答。邀请回答 hfgdzc 该类别下有 33 个回答。邀请回答 ggfvxv 该类别下有 33 个回答。邀请回答刘洋该类别下有 33 个回答。邀请回答 meihuacg 该类别下有 33 个回答。邀请回答 lining870815844 该类别下有 32 个回答。邀请回答 h1654155275.6678 该类别下有 32 个回答。邀请回答举报飘逸的D 相关推荐 • 怎样使用Matlab+Simulink去开发一种Cortex-M嵌入式处理器应用程序呢 3768 • 常用的ARM Cortex-M处理器有哪些？ 2716 • 怎样去使用Cortex-M内核中的精确延时方法呢 1022 • 基于Cortex-M处理器做产品开发为什么受欢迎 3946 • 怎样使用C++来编写Cortex-M系列MCU的程序呢 2050 • 什么是用于数字信号控制的CORTEX－M4处理器？ 1760 • 基于Cortex-M原型系统建立的Cortex-M3 DesignStart原型 1172 • cortex-m下各种微架构的区别是什么？ 987 • Cortex-A/Cortex-R/Cortex-M处理器怎么样？ 2211 • Arm Cortex-M处理器中M0的运算速率是不是最低 2508 3个回答

引言

  我们在平常使用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编译器，能够达到的效果是：故障原因自动诊断，自动分析故障原因，定位发生故障代码位置，输出错误现场的函数调用栈。

更加详细的说明可以访问 armink 大佬的 gitee仓库，有相关源码和文档说明，顺带给颗星~

  移植

  当前笔者所使用的平台是 keil 5,所使用的控制器是 STM32F103,我们准备一个具备串口功能的工程，工程结构如下所示：





  紧接着，我们来看下 cm_backtrace的源代码：





  上述中，cm_backtrace文件夹中存放的是源代码，我们需要将其全部复制到我们的工程目录，demos是使用的例子，里面分为有操作系统和无操作系统两种类型，然后tools存放的是工具，用命令行的形式来分析代码错误的工具,将相关文件复制到工程目录之后工程目录下的文件如下所示：





  然后，我们将相关文件添加至工程中，下面是添加之后的工程文件：





  同时应该添加相关头文件路径，添加的头文件路径如下所示：





  至此，cm_backtrace的源代码就添加完了，我们来编译一下。编译结果如下所示：





  可以发现有很多错误，这是因为我们的相关宏还没有打开，我们以照源码中的说明文档中的一个表，在 cmb_def.h中依次打开对应的宏，表如下所示：
  [tr]配置名称功能备注[/tr]

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

更改之后的代码如下所示：





  更改了宏之后，我们再来编译代码，编译结果如下所示：





  提示要开启c99编译模式，我们在keil中设置，设置方式如下所示：





  继续编译，看到还有一个错误信息，编译结果如下所示：





  这是因为cmb_fault.S中使用汇编定义了 HardFault_Handler函数，而在原本工程中，stm32f10x_it.c中已经定义了 HardFault_Handler，我们将stm32f10x_it.c中的HardFault_Handler注释掉，代码如下所示：





  现在编译就可以通过了。
  测试

  移植完之后，我们现在来测试一下，在单片机中除0造成的错误如何检查出来，我们在主函数中添加如下所示的代码：

#include "stm32f10x.h"
#include "bsp_usart.h"
#include

#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)
  {
  }
}
将程序烧录单片机，通过串口调试助手观查输出的信息：





  我们可以看到输出信息显示了当前用法错误是：企图除 0 操作，并给出了相关寄存器信息，但是我们还不知道出现错误的代码在哪一行，这个时候，就需要使用到前文所说的tools文件夹下的工具，addr2line工具。在使用这个工具的时候，需要知道当前工具输出的可执行文件的名字，我们打开keil,信息如下所示：





  然后，我们找到 cm_backtrace文件夹下的tools工具，将其复制到USART.axf所在的目录，复制之后的文件夹目录如下所示：





  在当前文件夹下打开 cmd窗口，然后运行addr2line -e USART.axf -a -f 08001844 0800189a,在这里提一下打开 cmd的方法，按住Shift键，然后右键，打开Powershell





  打开的 Powershell如下所示，并在Powershell中输入start cmd打开cmd窗口，然后在cmd窗口输入addr2line -e USART.axf -a -f 08001844 0800189a,结果如下所示：





  可以看到错误信息是fault_test.c的38行，我们打开源代码查看：





  可以看到确实是38行，问题分析正确。
  小结

  这就是本期分享的所有内容了，工欲善其事，必先利其器这话还是很有道理，学会使用各种分析工具也能够加快我们的开发进度，帮助我们更快更好地解决问题。

2021-11-26 09:43:30 评论

李建

引言

  我们在平常使用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编译器，能够达到的效果是：故障原因自动诊断，自动分析故障原因，定位发生故障代码位置，输出错误现场的函数调用栈。

更加详细的说明可以访问 armink 大佬的 gitee仓库，有相关源码和文档说明，顺带给颗星~

  移植

  当前笔者所使用的平台是 keil 5,所使用的控制器是 STM32F103,我们准备一个具备串口功能的工程，工程结构如下所示：





  紧接着，我们来看下 cm_backtrace的源代码：





  上述中，cm_backtrace文件夹中存放的是源代码，我们需要将其全部复制到我们的工程目录，demos是使用的例子，里面分为有操作系统和无操作系统两种类型，然后tools存放的是工具，用命令行的形式来分析代码错误的工具,将相关文件复制到工程目录之后工程目录下的文件如下所示：





  然后，我们将相关文件添加至工程中，下面是添加之后的工程文件：





  同时应该添加相关头文件路径，添加的头文件路径如下所示：





  至此，cm_backtrace的源代码就添加完了，我们来编译一下。编译结果如下所示：





  可以发现有很多错误，这是因为我们的相关宏还没有打开，我们以照源码中的说明文档中的一个表，在 cmb_def.h中依次打开对应的宏，表如下所示：
  [tr]配置名称功能备注[/tr]

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

更改之后的代码如下所示：





  更改了宏之后，我们再来编译代码，编译结果如下所示：





  提示要开启c99编译模式，我们在keil中设置，设置方式如下所示：





  继续编译，看到还有一个错误信息，编译结果如下所示：





  这是因为cmb_fault.S中使用汇编定义了 HardFault_Handler函数，而在原本工程中，stm32f10x_it.c中已经定义了 HardFault_Handler，我们将stm32f10x_it.c中的HardFault_Handler注释掉，代码如下所示：





  现在编译就可以通过了。
  测试

  移植完之后，我们现在来测试一下，在单片机中除0造成的错误如何检查出来，我们在主函数中添加如下所示的代码：

#include "stm32f10x.h"
#include "bsp_usart.h"
#include

#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)
  {
  }
}
将程序烧录单片机，通过串口调试助手观查输出的信息：





  我们可以看到输出信息显示了当前用法错误是：企图除 0 操作，并给出了相关寄存器信息，但是我们还不知道出现错误的代码在哪一行，这个时候，就需要使用到前文所说的tools文件夹下的工具，addr2line工具。在使用这个工具的时候，需要知道当前工具输出的可执行文件的名字，我们打开keil,信息如下所示：





  然后，我们找到 cm_backtrace文件夹下的tools工具，将其复制到USART.axf所在的目录，复制之后的文件夹目录如下所示：





  在当前文件夹下打开 cmd窗口，然后运行addr2line -e USART.axf -a -f 08001844 0800189a,在这里提一下打开 cmd的方法，按住Shift键，然后右键，打开Powershell





  打开的 Powershell如下所示，并在Powershell中输入start cmd打开cmd窗口，然后在cmd窗口输入addr2line -e USART.axf -a -f 08001844 0800189a,结果如下所示：





  可以看到错误信息是fault_test.c的38行，我们打开源代码查看：





  可以看到确实是38行，问题分析正确。
  小结

  这就是本期分享的所有内容了，工欲善其事，必先利其器这话还是很有道理，学会使用各种分析工具也能够加快我们的开发进度，帮助我们更快更好地解决问题。

2021-11-26 09:43:30 评论

李博

引言

  我们在平常使用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编译器，能够达到的效果是：故障原因自动诊断，自动分析故障原因，定位发生故障代码位置，输出错误现场的函数调用栈。

更加详细的说明可以访问 armink 大佬的 gitee仓库，有相关源码和文档说明，顺带给颗星~

  移植

  当前笔者所使用的平台是 keil 5,所使用的控制器是 STM32F103,我们准备一个具备串口功能的工程，工程结构如下所示：





  紧接着，我们来看下 cm_backtrace的源代码：





  上述中，cm_backtrace文件夹中存放的是源代码，我们需要将其全部复制到我们的工程目录，demos是使用的例子，里面分为有操作系统和无操作系统两种类型，然后tools存放的是工具，用命令行的形式来分析代码错误的工具,将相关文件复制到工程目录之后工程目录下的文件如下所示：





  然后，我们将相关文件添加至工程中，下面是添加之后的工程文件：





  同时应该添加相关头文件路径，添加的头文件路径如下所示：





  至此，cm_backtrace的源代码就添加完了，我们来编译一下。编译结果如下所示：





  可以发现有很多错误，这是因为我们的相关宏还没有打开，我们以照源码中的说明文档中的一个表，在 cmb_def.h中依次打开对应的宏，表如下所示：
  [tr]配置名称功能备注[/tr]

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

更改之后的代码如下所示：





  更改了宏之后，我们再来编译代码，编译结果如下所示：





  提示要开启c99编译模式，我们在keil中设置，设置方式如下所示：





  继续编译，看到还有一个错误信息，编译结果如下所示：





  这是因为cmb_fault.S中使用汇编定义了 HardFault_Handler函数，而在原本工程中，stm32f10x_it.c中已经定义了 HardFault_Handler，我们将stm32f10x_it.c中的HardFault_Handler注释掉，代码如下所示：





  现在编译就可以通过了。
  测试

  移植完之后，我们现在来测试一下，在单片机中除0造成的错误如何检查出来，我们在主函数中添加如下所示的代码：

#include "stm32f10x.h"
#include "bsp_usart.h"
#include

#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)
  {
  }
}
将程序烧录单片机，通过串口调试助手观查输出的信息：





  我们可以看到输出信息显示了当前用法错误是：企图除 0 操作，并给出了相关寄存器信息，但是我们还不知道出现错误的代码在哪一行，这个时候，就需要使用到前文所说的tools文件夹下的工具，addr2line工具。在使用这个工具的时候，需要知道当前工具输出的可执行文件的名字，我们打开keil,信息如下所示：





  然后，我们找到 cm_backtrace文件夹下的tools工具，将其复制到USART.axf所在的目录，复制之后的文件夹目录如下所示：





  在当前文件夹下打开 cmd窗口，然后运行addr2line -e USART.axf -a -f 08001844 0800189a,在这里提一下打开 cmd的方法，按住Shift键，然后右键，打开Powershell





  打开的 Powershell如下所示，并在Powershell中输入start cmd打开cmd窗口，然后在cmd窗口输入addr2line -e USART.axf -a -f 08001844 0800189a,结果如下所示：





  可以看到错误信息是fault_test.c的38行，我们打开源代码查看：





  可以看到确实是38行，问题分析正确。
  小结

  这就是本期分享的所有内容了，工欲善其事，必先利其器这话还是很有道理，学会使用各种分析工具也能够加快我们的开发进度，帮助我们更快更好地解决问题。

2021-11-26 09:43:30 评论

石径

搜索历史

相关推荐

精选推荐

最新话题

热门话题

创建小组步骤

站长推荐 /7