Cortex-M3 内核HardFault错误调试定位方法
Cortex-M3 内核HardFault错误调试定位方法
1、首先更改startup.s的启动文件，把里面的HardFault_Handler代码段换成下面的代码：
HardFault_Handler\
PROC
IMPORT hard_fault_handler_c
TST LR, #4
ITE EQ
MRSEQ R0, MSP
MRSNE R0, PSP
B hard_fault_handler_c
ENDP
2、然后把hard_fault_handler_c函数放在c文件的代码中。代码如下：
void hard_fault_handler_c(unsigned int * hardfault_args)
{
static unsigned int stacked_r0;
static unsigned int stacked_r1;
static unsigned int stacked_r2;
static unsigned int stacked_r3;
static unsigned int stacked_r12;
static unsigned int stacked_lr;
static unsigned int stacked_pc;
static unsigned int stacked_psr;
static unsigned int SHCSR;
static unsigned char MFSR;
static unsigned char BFSR;
static unsigned short int UFSR;
static unsigned int HFSR;
static unsigned int DFSR;
static unsigned int MMAR;
static unsigned int BFAR;
stacked_r0 = ((unsigned long) hardfault_args[0]);
stacked_r1 = ((unsigned long) hardfault_args[1]);
stacked_r2 = ((unsigned long) hardfault_args[2]);
stacked_r3 = ((unsigned long) hardfault_args[3]);
stacked_r12 = ((unsigned long) hardfault_args[4]);
/*异常中断发生时，这个异常模式特定的物理R14,即lr被设置成该异常模式将要返回的地址*/
stacked_lr = ((unsigned long) hardfault_args[5]);
stacked_pc = ((unsigned long) hardfault_args[6]);
stacked_psr = ((unsigned long) hardfault_args[7]);
SHCSR = (*((volatile unsigned long *)(0xE000ED24))); //系统Handler控制及状态寄存器
MFSR = (*((volatile unsigned char *)(0xE000ED28))); //存储器管理fault状态寄存器
BFSR = (*((volatile unsigned char *)(0xE000ED29))); //总线fault状态寄存器
UFSR = (*((volatile unsigned short int *)(0xE000ED2A)));//用法fault状态寄存器
HFSR = (*((volatile unsigned long *)(0xE000ED2C))); //硬fault状态寄存器
DFSR = (*((volatile unsigned long *)(0xE000ED30))); //调试fault状态寄存器
MMAR = (*((volatile unsigned long *)(0xE000ED34))); //存储管理地址寄存器
BFAR = (*((volatile unsigned long *)(0xE000ED38))); //总线fault地址寄存器
while (1);
}
3、执行程序后，若发生内核错误，则程序会运行到最后的while(1)处。此时观察相应的堆栈和故障寄存器值， stacked_lr即为故障发生时进入故障中断前pc的值，在MDK软件调试状态下，假如stacked_lr的值为0x1A002D08，在左下方的命令窗口输入“pc = 0x1A002D08”，回车，即可定位发生错误的代码位置。
4、根据内核错误状态寄存器的值，对应下面的说明，也可以看出是发生了何种内核错误。
附录：Cortex-M3内核错误寄存器说明
程序调试技巧大揭秘：如何快速定位错误
程序调试技巧大揭秘：如何快速定位错误
程序调试是软件开发过程中不可或缺的一环，它能帮助开发者定位和修复程序的错误。针对程序调试，有许多有效的技巧和方法可以帮助开发者更快地定位问题，接下来我们将介绍一些常用的程序调试技巧，以帮助开发者在调试过程中更加高效地找到错误。
1.理解问题和目标：在开始调试之前，要确保对程序的问题和预期目标有充分的理解。了解程序的预期行为有助于从整体上捕捉问题，定位问题所在。
2.输出调试信息：在程序中加入输出调试信息的语句是一种常用且有效的调试方法。通过输出变量的值、程序流程的跟踪等信息，可以帮助开发者了解程序的执行情况，从而定位错误。
3.利用断点调试：调试器中的断点功能可以让程序在指定位置暂停执行，开发者可以逐步观察程序的执行过程和变量的变化，从而定位错误。通过断点调试，开发者可以快速找到错误的位置，减少调试的时间。 4.分而治之：当程序较大且复杂时，可以将程序分成较小的部分进行调试。通过逐步调试每个小部分，可以减少调试的复杂性，更容易定位错误。
5.逆向调试：逆向调试是一种有力的调试技巧，它将一个问题视为一个谜题，通过逆向思维来找到问题所在。逆向调试可以帮助开发者理解程序执行的逻辑，帮助定位隐蔽的错误。
6.使用调试工具：现代集成开发环境（IDE）通常都提供了一些强大的调试工具，如变量监视器、调用堆栈跟踪器等。利用这些工具，开发者可以跟踪变量的值、查看函数调用的层级关系等，有助于快速定位错误。
7.运用二分法：当问题的范围较大或者不清楚错误的具体位置时，可以尝试使用二分法逐步缩小问题的范围。通过将程序的一半代码注释掉，确定问题是否仍然存在，从而缩小问题所在的范围。
8.回顾版本控制记录：如果问题是在程序的某个特定版本中引入的，可以回顾版本控制系统中的记录，找到引入错误的具体提交，并比较不同版本之间的差异，从而定位问题的源头。 9.与其他开发者协作：有时，一个问题可能需要多个开发者联合调试，因为一个人可能无法完全了解整个程序的各个部分。与其他开发者交流并共同分析问题，可以加快问题解决的速度。
STM32硬件错误HardFault
STM32硬件错误HardFault
STM32出现HardFault_Handler故障的原因主要有两个方面：
1、内存溢出或者访问越界。
2、堆栈溢出。
最近遇到的问题是栈溢出，情况是这样的，举例说明：
static char data[10000];
void fun1(unsigned char *buf)
{
int i=0;
for(i=0; i<5000; i++)
{
data = buf;
}
}
void fun2(void)
{
unsigned char buf[5000];
.........;
fun1(buf); //执行完毕此函数出现硬件错误HardFault_Handler
printf("data: %s\r\n",buf);
}
int main()
{
.........();
.........(); .........();
fun2();
.........();
.........();
.........();
while();
}
问题分析，通过断点代码跟踪，在进入fun1(buf);函数时，发现SP指向了数组data所开辟的空间，同时PC、等寄存器值压入栈，在循环执行data = buf;的时候修改了压入栈的数据，导致在退出函数fun1(buf);时PC指向了错误的位置。
问题：为什么SP会指向数组data所开辟的空间？原因是发生了栈溢出。
问题：那里导致了堆栈溢出呢？ 下面我们看下面的网络资料，认识一下堆栈。
**************************************************************************************************
int main()
{
while(1);
}
BUILD://Program Size: Code=340 RO-data=252 RW-data=0
MCU常见故障定位方法
MCU常见故障定位方法
MCU常见故障定位方法
掌握MCU常见故障的定位方法可有助于问题分析及尽快解决。
1、排除法--排除法是快速排查故障原因，定位、解决故障常用的一种方法。
例如：客户端登录不成功，经过检查，用户名、密码都正确，排除用户名密码输入错误的原因。检查网络连接，发现连接都正常，排除网络中断的可能。然后再检查服务器地址是否正确，登录进程是否被占用等之类的原因，逐层排除缩小范围找到故障发生的根本原因。
2、案例法--MCU提供常见故障案例，用户可以参考相似的故障案例解决遇到的一般故障。案例分析法是指一些故障发生的原因和解决的方法具有相似性，用户可以查看《故障案例》中是否有与遇到的故障相似的案例，如果有可以参考案例进行故障的处理。
3、网络分析法--一些故障通常是由于网络不通或者网络质量差引起的，您可以通过以下测试命令测试网络连通性和网络质量。
执行ping x.x.x.x命令，ping目标网元的IP地址，检测网络是否正常；利用tracert x.x.x.x 命令定位网络故障。
4、告警分析法--当MCU中的部件出现异常时或业务操作异常，会通过告警上报故障信息。告警分析是及时获知故障信息的重要途径，能够帮助您及时发现系统运行中的故障信息，并根据告警建议及时进行故障定位和故障排除。
告警优先级：紧急告警、重要告警、一般告警、提示告警
FlashdownloadfailedCortexM3的原因及解决办法
FlashdownloadfailedCortexM3的原因及解决办法
Flash download failed-Cortex-M3的原
因及解决办法
首先，此类错误基本是被STM32芯片遇到，并且基本都
是使用JLINK仿真器，其实我们以下的方法不一定可以
帮你解决问题，问题真正的原因我们也没有在这个帖子
公开、如果需要解决，请联系armjishu的JLINK仿真器工程师，他会帮助你解决的；生产的JLINK可以解决这
个问题。
MDK中出现 Error: Flash download
failed-"Cortex-M3"的原因及解决办法：
1.Jtag模式下，主要是芯片大小选错
出现这处问题通常是MDK中的Flash的编程算法没有配置或没有配置正确，
神舟系列用的是STM32芯片。
在主菜单中打开Flash->;Configure Falsh Tools
配置窗口，切换到“Utilities"页。
按“Setting"按钮进入“Flash download setup"配置窗口
然后一路按“OK”按钮退出配置窗口。
在“Flash download setup"配置窗口点击
“Add”按钮进入“Add Flash Programming Algorlthm"窗口
在“Add Flash Programming Algorlthm"窗口，根据你实际使用的芯片选择，这里的神舟III号STM32
开发板用的是STM32F103ZET6，应先择"STM32F10X 128kB
Flash",选定编程算法后，按
“Add”按钮。
2.如果是在SWD模式下，Debug菜单中，Reset菜单选项（Autodetect/HWreset/sysresetReq/Vectreset）默认是AutoDetect，改成SysResetReq即可。
Cortex-M3 异常和中断
0.前言
本文想解决的问题有：
如何开启、关闭中断
如何开启、关闭异常
LPC177x/8x支持的中断优先级个数
复位后，异常/中断默认的优先级
如何设置异常/中断的优先级
什么是优先级组，如何设置优先级组，复位后的优先级组
1. Cortex-M3的异常/中断屏蔽寄存器组
注:只有在特权级下，才允许访问这3个寄存器。
名 字 功能描述
PRIMASK 只有单一比特的寄存器。置为1后，就关掉所有可屏蔽异常，只剩下NMI和硬Fault可以响应。默认值是0，表示没有关闭中断。
FAULTMASK 只有单一比特的寄存器。置为1后，只有NMI可以响应。默认值为0，表示没有关异常。
BASEPRI 该寄存器最多有9位（由表达优先级的位数决定）。定义了被屏蔽优先级的阈值。当它被设置为某个值后，所有优先级号大于等于此值的中断都被关。若设置成0，则不关断任何中断，0为默认值。
注：寄存器BASEPRI的有效位数受系统中表达优先级的位数影响，如果系统中只使用3个位来表达优先级，则BASEPRI有意义的值仅为0x00、0x20、0x40、0x60、0x80、0xA0、0xC0和0xE0
使用MRS/MSR指令访问这三个寄存器，比如：
MRS R0, BASEPRI ;读取BASEPRI到R0中
MSR BASEPRI, R0 ;将R0数据写入到BASEPRI中
为了快速的开关中断，CM3还专门设置了一条CPS指令，有四种用法：
CPSID I ；PRIMASK=1，关中断
CPSIE I ；PRIMASK=0，开中断
CPSID F ；FAULTMASK=1，关异常
CPSIE F ；FAULTMASK=0，开异常
CMSIS-M3微控制器软件接口标准中的core_cm3.h给出了开关中断或异常的函数：
stm32 iar hardfault 8位 位域 结构
1 / 2 stm32 iar hardfault 8位 位域 结构 STM32微控制器上使用IAR Embedded Workbench时发生的硬件故障（HardFault）。"HardFault"通常指的是处理器因无法处理的严重错误而引发的异常。 在硬件故障的调试过程中，可以查看HardFault异常的状态寄存器以获取更多信息，以便找出问题的根本原因。以下是一个可能的C语言结构和位域的例子，用于查看HardFault异常状态寄存器： #include typedef struct { uint32_t CFSR; // Configurable Fault Status Register uint32_t HFSR; // Hard Fault Status Register uint32_t DFSR; // Debug Fault Status Register uint32_t AFSR; // Auxiliary Fault Status Register } SCB_Type; // 定义SCB寄存器的地址 #define SCB_BASE_ADDR ((uint32_t)0xE000ED00U) #define SCB ((SCB_Type *)SCB_BASE_ADDR)
2 / 2 int main(void) { // 在HardFault异常时，读取Hard Fault Status Register if (__get_IPSR() == HardFault_IRQn) { uint32_t hardFaultStatus = SCB->HFSR; // 现在你可以处理hardFaultStatus，找出HardFault的具体原因 // ... // 重置HardFault异常，继续执行 SCB->HFSR |= 0x40000000; } // 其他初始化和代码... while (1) { // 主循环... } } 这个例子假设你的STM32芯片使用的是Cortex-M架构。请注意，具体的寄存器和位域可能会因芯片型号的不同而有所不同，因此请查阅你的芯片手册和Cortex-M架构参考手册以获取准确的信息。
STM32在keil下使用jlink时产生错误的解决方法
如果对你有帮助，请下载使用！
1 最近一段时间一直在学习STM32和ucos的移植，使用的开发环境是keil u4版本。仿真器是80元买的jlink。
在学习了STM32固件库和ucos内核与移植相关的程序之后，写了一个流水灯程序，准备下载到板子上看看情况。哪知程序还没有下进去，在debug时，keil的错误提示到：Error: Flash download failed-"Cortex-M3"
感觉这么错误很普遍，也是初学者常常遇到的错误，下面我就将这个错误产生的原因和解决方法赘述一下：
错误产生的原因和分析，解决。
首先，我们看到提示信息是有关flash的，那么我们来查看一下STM32F103XB的数据手册关于这部分的描述（我使用的芯片是STM32F103RB，有128kflash。） 知道了原来flash在此芯片中的地址是从
0x0800 0000到0x0801 FFFF 这段，也就是说这段存储空间是用来存储程序。而在STM32芯片方面，它又有一个规则，那就是芯片启动的方式，如果你把程序下载到了flash中，那么在复位芯片之前或者通电之前，要将boot0，boot1两个引脚拉到高电平，这样在启动时，芯片初始化之后，运行程序代码才是从flash地址开始执行的。
于是，我们来查看一下keil中仿真器的设置，是不是正确，设置的选项在keil软件的project-options for target中的Utilities中，先来查看下仿真器是否选对，然后点settings，弹出如下菜单：
查看一下programming Algorism 下的flash地址是否正确，如果不正确则会引起开始那个错误的提示信息，
如果正确还是出现那个错误，那么按照官方给的解决方法是，删除现有的flash地址，重新配置一下，记得要选对芯片型号和地址空间。配置好之后点击OK退出。然后再查看一下Target中的地址，是否跟你重新添加的一致，如果一致，那么点OK退出。然后重新编译链接即可。
cortex-m3 软复位 指令
cortex-m3 软复位 指令
Cortex-M3是一款32位的嵌入式微控制器处理器。软复位是指通过软件控制的方式对处理器进行复位操作。在Cortex-M3中，软复位指令可以通过特定的写入特殊的值到复位控制寄存器来实现。
Cortex-M3处理器中的复位控制寄存器是一个特别的寄存器，用于控制复位和重启相关的操作。这个寄存器叫做NVIC_VTOR（Vector Table Offset Register）。它的地址是0xE000ED08，通过向这个地址写入特定的值，可以控制处理器进行软复位操作。
在进行软复位操作之前，我们需要先了解一下NVIC_VTOR寄存器的结构和作用。这个寄存器是一个32位的寄存器，用于存储向量表的基地址。向量表是一个存储了处理器的中断向量和异常处理程序入口地址的数据结构。通过修改NVIC_VTOR寄存器的值，可以改变向量表的位置，从而改变中断和异常处理程序的入口地址。
软复位操作的步骤如下：
1. 将要复位的值写入NVIC_VTOR寄存器。可以通过将该值写入到0xE000ED08地址处来完成这个操作。写入的值可以是任意的32位值，但通常情况下会设置为0，将向量表的起始位置重置为默认值。
2. 在软复位之前，需要先禁止中断。这可以通过设置处理器的特殊标志位PRIMASK来实现。PRIMASK是一个位于特殊寄存器CPSR的第7位（bit[7]）的标志位，置1表示禁止中断，置0表示允许中断。通过将PRIMASK设置为1，可以禁止中断，确保在软复位过程中不会发生中断。
3. 执行软复位操作。软复位操作将会将NVIC_VTOR寄存器的值加载到执行地址寄存器（PC）中，从而将处理器的执行位置重置到向量表的起始位置。
4. 启用中断。在复位之后，为了确保处理器可以正常响应中断请求，我们需要将之前禁止的中断重新开启。这可以通过将PRIMASK置0来实现。
软复位操作可以用来重新启动处理器，将处理器恢复到其初始状态。在嵌入式系统中，软复位常常用于处理器初始化、系统调试和异常处理等场景。
ARM Cortex-M3处理器故障的分析与处理
…………………………一皇 技术一 Ｊ
ＡＲＭ Ｃｏｒｔｅｘ—Ｍ３处理器故障的分析与处理
阿城继电器股份有限公司 孙洪蛟
【摘要】本文介绍了ＡＲＭ Ｃｏｒｔｅｘ—Ｍ３处理器的４种故障：总线故障、用法故障、内存管理故障和硬故障。分析了这些故障产生的原因，叙述了如何通过故障状态寄 存器找出故障原因，如何在程序开发阶段尽可能的避免故障的产生，以及故障的处理方法。 【关键词】ＡＲＭ；故障；寄存器；中断
１．引言 在嵌入式领域，ＡＲＭ Ｃｏｒｔｅｘ—Ｍ３处理器凭借其高性能、低功耗、低成本等优势， 得到了广泛的应用。该处理器具有很强的灵活性，在给开发人员较大开发空间的同
时，也在一定程度上增加了开发的难度。尤其是当处理器出现故障时，故障原因常常
难以找出。本文针对该处理器的以上特点，详细分析了处理器的４种故障，使读者可以
对故障进行准确的分析和处理。
２．故障分析 ＡＲＭ Ｃｏｒｔｅｘ—Ｍ３处理器…共有４种故障：总线故障、用法故障、内存管理故障和硬故
障。ＡＲＭ将故障当作特殊的中断来处理，其中，硬故障在所有故障中拥有最高优先级，
优先级为一ｌ 其它故障的优先级是可整定的，但必须为非负数，默认优先级是０（ＡＲＭ 中优先级的数值越小，优先级的级别越高，负数拥有最高优先级 ）。总线故障是指指
令或数据在ＡＨＢ总线上传输时出现错误而产生的一种故障，可在指令读取、数据读写以
及堆栈的压栈和弹栈时产生。用法故障是指在对ＣＰＵ的使用上出现错误而导致的故障。
内存管理故障是指对内存的读写违反了ＭＰＵ（内存保护单元）的规定或在不允许执行指
令的地址执行指令而产生的一种故障。硬故障一般由其它故障升级导致。下面将对每
种故障进行详细分析。
２．１总线故障
总线故障产生的原因有以下几种：读写错误的内存地址（如对一处内存地址进行 读写，但该地址并没有连接内存）；对一个设备进行读写，但该设备还没有准备好接
受读写操作（如读写外部ＲＡＭ，但外部ＲＡＭ还没有初始化）；对设备读写的数据类型不符
芯片加仿真 link-cortex-m error -回复
芯片加仿真 link-cortex-m error -回复
芯片加仿真是一个重要的过程，用于验证和优化芯片设计。然而，在进行芯片加仿真时，可能会遇到各种错误和挑战，其中一个常见的错误是“linkcortexm错误”。本文将一步一步回答关于芯片加仿真和linkcortexm错误的问题，以帮助读者更好地理解和解决这个错误。
第一步：了解芯片加仿真的基本概念
在芯片设计过程中，芯片加仿真是一个重要的步骤，用于验证设计的正确性和性能。芯片加仿真通常分为逻辑仿真和物理仿真两个阶段。逻辑仿真用于验证设计的逻辑功能，而物理仿真则用于验证设计的电气性能和时序。
第二步：了解linkcortexm错误的背景
Link是一个用于连接应用程序和硬件的工具。Cortex-M是一种常见的ARM处理器架构，被广泛应用于嵌入式系统设计中。LinkCortex-M是一个用于链接Cortex-M处理器应用程序的工具。
在进行芯片加仿真时，可能会遇到linkcortexm错误。这种错误通常是由于应用程序与硬件之间的不兼容性或配置错误导致的。
接下来，我们将介绍几种常见的linkcortexm错误和解决方法。
第三步：常见的linkcortexm错误和解决方法 1. 链接错误：在链接过程中，linker可能会报告无法解析符号或找不到某些函数的错误。这通常是由于缺少相应的库文件或函数声明错误导致的。解决方法是确保所有的库文件都正确添加到项目中，并检查函数声明是否正确。
2. 内存错误：芯片加仿真中最常见的错误之一是内存问题。例如，堆栈溢出和内存分配错误可能导致应用程序运行异常。解决方法是仔细检查应用程序中的内存分配和释放操作，确保它们正确地管理内存。
3. 配置错误：linkcortexm错误还可能是由于错误的配置导致的。例如，错误的链接脚本或链接选项可能导致无法正确链接应用程序。解决方法是检查链接脚本和链接选项，确保它们与硬件和应用程序的需求相匹配。