应对STM32 CortexM3 HardFault异常.docx
《应对STM32 CortexM3 HardFault异常.docx》由会员分享,可在线阅读,更多相关《应对STM32 CortexM3 HardFault异常.docx(15页珍藏版)》请在冰豆网上搜索。
![应对STM32 CortexM3 HardFault异常.docx](https://file1.bdocx.com/fileroot1/2023-6/17/c0da1d7a-48f9-44b2-872d-fdae62d65e1b/c0da1d7a-48f9-44b2-872d-fdae62d65e1b1.gif)
应对STM32CortexM3HardFault异常
STM32Cortex-M3HardFault
Hardfault(硬错误,也有译为硬件错误的)是在STM32(如无特别说明,这里的STM32指的是Cortex-M3的核)上编写程序中所产生的错误,造成HardFault错误的原因也是最为纷繁复杂的。
由于能导致该错误的原因很多,所以一但出现,比较难找到其原因。
网上有很多类似的这种方法,现在我将其稍加整理,并结合我曾经遇到过的问题,详细说明。
硬fault是总线fault、存储器管理fault以及用法fault上访的结果。
如果这些fault的服务例程无法执行,它们就会成为“硬伤”——上访(escalation)成硬fault。
另外,在取向量(异常处理是对异常向量表的读取)时产生的总线fault,也按硬fault处理。
在NVIC中有一个硬fault状态寄存器(HFSR),它指出产生硬fault的原因。
如果不是由于取向量造成的,则硬fault服务例程必须检查其它的fault状态寄存器,以最终决定是谁上访的。
1寄存器描述
首先查看硬故障寄存器,判别原因。
对于调试故障,有个调试故障寄存器,在0xE000ED30处,有详细介绍,不做探讨;
对于取中断发生的,有两类原因,一是在取向量过程中发生总线fault,二是向量表偏移量设置有误。
本文重点介绍位30所示的,上访类错误。
这样Fault类异常有了三类,用法错误,存储管理错误,总线错误。
对于这些寄存器详尽的描述,见权威指南。
2确定发生错误的地方
2.1查找出错原因
Cortex-M3有双堆栈功能,在带有操作系统时,一般都会使用。
在Keil软件使用JTAG调试为例,系统的启动文件中,将断点打在下面4个地方。
HardFaultException
BHardFaultException
MemManageException
BMemManageException
BusFaultException
BBusFaultException
UsageFaultException
BUsageFaultException
程序跑飞以后,就会停在上面的4个断点的一个地方。
可以通过两种方式查找原因。
第一种,在KEIL软件下,利用软件提供的功能查找故障原因。
在点出的窗口中,可以大体确定是哪个寄存器、什么原因造成了HardFault。
第二种,通过在内存观察窗口,直接输入上面那些寄存器的值来确定,通过观看寄存器那个位被置1了,确定出错原因。
2.2确定出错地方
然后查看左侧寄存器栏中Banked确定现在使用的是那个堆栈,MSP或者是PSP,确定以后,在内存查看窗口,输入堆栈的地址,以这个地址开始的8个32位数值,应该依次是R0,R1,R2,R3,R12,R14,R15,XPSR的数值,据此判定你的堆栈地址是不是对的(有时需要考虑堆栈的增长方向)。
R14,R15的地址就是我们出错的代码所在的地址,需要在这个地址基础上,首先偶数对齐,然后向上减去8个字节。
需要考虑的是,在使用MSP的时候,有出错的地方并不一定在R14,R15处,而是在XPSR往后的第二个地址处,在这个附近查找,排除故障。
3两个例子
下面就我之前碰到过的,举例说明,这两个例子分析出结果后,会觉得很简单,但是查找原因的过程有点费劲。
3.1memcpy内存拷贝函数引发
总线故障寄存器中IMPERCISERR位,标示不精确的数据总线访问错误,权威指南中对此有详尽的说明,“或者传送的数据单位尺寸不能为设备所接受,此时有可能是LDM/STM指令造成的”。
Memcpy函数的原因是这样的void*memcpy(void*dest,constvoid*src,size_tn),其中src是源地址,dest是目的地址,n是要拷贝的字节长度。
KEIL自带的函数中并不检查这三个参数是否有效,我所开发的程序中,源地址和目的地址都在外存(外部扩展的内存,本次大小是4M)中,假设size的大小是0xFFFFFFFF,这样的数值非常的大,单纯的拷贝都需要10多秒。
程序中定义了很多的变量都在外存,这个拷贝函数所在的任务优先级比较低,可能被中断或者其它的任务打断。
我调试程序的时候,首先是发生在了中断的地方,外存数组地址到了0x21FF2200,原来定义在68021000,加起来立刻超出了外存大小。
修改中断,最终确定是传入的参数n太大了,直接是0xFFFFFFFF,这样memcpy函数会在这里陷入死循环,一直到外存耗尽,地址再增加,找不到外存地址了,然后触发HardFault。
3.2滥用临界区
程序中的一些关键代码,有时候需要在临界区中执行,但是临界区若使用不当,则也会造成错误。
OS_ENTER_CRITICAL();
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
OS_EXIT_CRITICAL();
#defineOS_ENTER_CRITICAL(){cpu_sr=OS_CPU_SR_Save();}
OS_CPU_SR_Save
MRSR0,PRIMASK;保存全局中断标志;
CPSIDI;关中断
BXLR
将全局中断标志保存到R0中,此时R0是0,CPSIDI则执行关中断命令,此时PRIMASK是1。
#defineOS_EXIT_CRITICAL(){OS_CPU_SR_Restore(cpu_sr);}
OS_CPU_SR_Restore
MSRPRIMASK,R0;恢复全局中断标志
BXLR
将R0放入全部中断寄存器中,则允许所有中断了。
程序中如何保护R0的,细看汇编发现,实际上在执行关中断后,将R0保存到了sp+8处,开中断时再取出来,这样才保证了不会被修改。
STRr0,[sp,#0x08]tPendTimes=0;
同时,开中断,LDRr0,[sp,#0x08],则从sp+8处取出来,保存到R0中。
临界区中的代码完成如下内容:
netconn_write(tradeconn,g_u8TcpSendBuf,l_u32CodeSendLen,NETCONN_COPY);
调用TCPIP_APIMSG(&msg);,
sys_mbox_post(mbox,&msg);
OSQPost(mbox->hMBox,msg)发送消息,OS_EventTaskRdy函数修改线程的状态,使OSTCBStatPend变为等待完毕;
此时若协议栈线程优先级高于当前任务,则会触发任务调度,悬起OSPendSV,但是由于关闭了中断,即使在调用OS_ENTER_CRITICAL()后,也无法打开中断,故不能执行中断,任务无法切换。
同理,调用sys_arch_sem_wait(apimsg->msg.conn->op_completed,0);,也无法阻塞自身,执行任务调度,程序在临界区里面变成了单线程在跑。
一直等待代码执行完毕开中断后,悬起的软中才能执行,本来应该在发送消息和等待消息处执行任务切换的,现在只能等待临界区执行完毕后,才能执行任务切换中断。
此刻的PSP是0x2000DFAC,临界区的那段代码我们也有压栈操作,即是0x2000DFAC后面的内容也是我们需要的,如下图所示。
原来的内容是这样的,如下图所示:
此时在OSPendSV中,执行如下语句
MRSR0,PSP;PSPisprocessstackpointer
CBZR0,OSPendSV_nosave;
SUBSR0,R0,#0x20;saveremainingregsr4-11onprocessstack
STMR0,{R4-R11}
从PSP-32个字节处开始,保存R4到R11这8个寄存器32个字节,则原来的内容都被覆盖了,而这些内容正好是我们需要的。
被修改后的截图如所示,原来的内容被改成R4到R11这几个寄存器的值。
其中从0801556D变成了68130000,协议栈线程如下执行。
msg->msg.apimsg->function(&(msg->msg.apimsg->msg));
函数的地址变成了68130000,而68130000,是我们的外存,
在这里执行代码0x68130006F63A07E1DCD0xF63A07E1;?
Undefined
最终是这句话,触发了Hardfault。
3.3运行中记录出错位置
以3.2为例子,进行简单的反推。
启动文件中的Hard中断处理一般如下所示,即让程序陷入这个死循环。
HardFaultException
;BHardFaultException
现在我们要在记录重要数据,即此刻系统的运行情况,主要包括:
此刻堆栈情况、以及R0等8个寄存器的值、相关Hard硬件寄存器的值,若是任务引发的,还要记录任务的ID号,因此修改这个异常处理函数。
HardFaultException
TSTLR,#4;将LR的值与4按位相与
ITEEQ//若为0则是MSP,否则是PSP
MRSEQR0,MSP
MRSNER0,PSP
Bhard_fault_handler_c//这个是C语言编写的函数
voidhard_fault_handler_c(unsignedint*hardfault_args)
{
unsignedintstacked_r0,stacked_r1,stacked_r2,stacked_r3;
unsignedintstacked_r12,stacked_lr,stacked_pc,stacked_psr;
stacked_r0=((unsignedlong)hardfault_args[0]);
stacked_r1=((unsignedlong)hardfault_args[1]);
stacked_r2=((unsignedlong)hardfault_args[2]);
stacked_r3=((unsignedlong)hardfault_args[3]);
stacked_r12=((unsignedlong)hardfault_args[4]);
stacked_lr=((unsignedlong)hardfault_args[5]);
stacked_pc=((unsignedlong)hardfault_args[6]);
stacked_psr=((unsignedlong)hardfault_args[7]);
sprintf((char*)g_cDataBuf,"[Hardfaulthandler]\n");
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"Thetaskpriid=0x%0.8x\n",OSPrioCur);//任务ID号
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"SP=0x%0.8x\n",hardfault_args);//堆栈地址
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"R0=0x%0.8x\n",stacked_r0);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"R1=0x%0.8x\n",stacked_r1);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"R2=0x%0.8x\n",stacked_r2);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"R3=0x%0.8x\n",stacked_r3);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"R12=0x%0.8x\n",stacked_r12);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"LR=0x%0.8x\n",stacked_lr);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"PC=0x%0.8x\n",stacked_pc);
Usart232SendStr(g_cDataBuf);
sprintf((char*)g_cDataBuf,"PSR=0x%0.8x\n",stacked_psr);
Usart232SendStr(g_cDataBuf);
exit(0);//terminate
return;
}
以3.2为例,发生异常后,串口的输出入下所示:
[Hardfaulthandler]
Thetaskpriid=0x00000014//任务优先级是20
SP=0x200077d8//当前任务的堆栈地址是0x200077D8
R0=0x2000dfa0
R1=0x68130000
R2=0x2000df9c
R3=0x20002100
R12=0x00000001
LR=0x0801c7fb//分析得出,这个地址就是出错的地方
PC=0x68130000
PSR=0x00000000
此时需要借助map文件分析,map文件中得出对应的代码和数据位置。
tcpip_thread0x0801c7adThumbCode190tcpip.o(i.tcpip_thread)
i.tcpsvr_accept_200x0801c874Section64ftpmanage.o(i.tcpsvr_accept_20)
0x0801c7fb应该在tcpip文件中的tciip_thread函数里。
T_LWIP_THREAD_STK0x20007000Data2048sys_arch.o(.bss)
rsuPib0x20007800Data32para.o(.bss)
堆栈空间是0x200077D8,是在T_LWIP_THREAD_STK这个栈空间里,这也是协议栈任务的堆栈空间,证明判断的任务优先级为20是正确的。
从0x0801C7AD处开始的16进制文件如下图所示,再将汇编文件列出(需要KeiL生成)。
tcpip_threadPROC
;;;232staticvoid
;;;233tcpip_thread(void*arg)
000000b508PUSH{r3,lr}//开始
;;;234{
;;;235structtcpip_msg*msg;
;;;236LWIP_UNUSED_ARG(arg);
;;;237
;;;238#ifIP_REASSEMBLY
;;;239sys_timeout(IP_TMR_INTERVAL,ip_reass_timer,NULL);
;;;240#endif/*IP_REASSEMBLY*/
;;;241#ifLWIP_ARP
;;;242sys_timeout(ARP_TMR_INTERVAL,arp_timer,NULL);
0000022200MOVSr2,#0
000004492eLDRr1,|L11.192|
000006f2413088MOVr0,#0x1388
00000af7fffffeBLsys_timeout
;;;243#endif/*LWIP_ARP*/
;;;244#ifLWIP_DHCP
;;;245sys_timeout(DHCP_COARSE_TIMER_MSECS,dhcp_timer_coarse,NULL);
;;;246sys_timeout(DHCP_FINE_TIMER_MSECS,dhcp_timer_fine,NULL);
;;;247#endif/*LWIP_DHCP*/
;;;248#ifLWIP_AUTOIP
;;;249sys_timeout(AUTOIP_TMR_INTERVAL,autoip_timer,NULL);
;;;250#endif/*LWIP_AUTOIP*/
;;;251#ifLWIP_IGMP
;;;252sys_timeout(IGMP_TMR_INTERVAL,igmp_timer,NULL);
;;;253#endif/*LWIP_IGMP*/
;;;254#ifLWIP_DNS
;;;255sys_timeout(DNS_TMR_INTERVAL,dns_timer,NULL);
;;;256#endif/*LWIP_DNS*/
;;;257
;;;258if(tcpip_init_done!
=NULL){
00000e482dLDRr0,|L11.196|
0000106800LDRr0,[r0,#0];tcpip_init_done
000012b128CBZr0,|L11.32|
;;;259tcpip_init_done(tcpip_init_done_arg);
000014482bLDRr0,|L11.196|
0000161d00ADDSr0,r0,#4
0000186800LDRr0,[r0,#0];tcpip_init_done_arg
00001a492aLDRr1,|L11.196|
00001c6809LDRr1,[r1,#0];tcpip_init_done
00001e4788BLXr1
|L11.32|
;;;260}
;;;261
;;;262LOCK_TCPIP_CORE();
;;;263while
(1){/*MAINLoop*/
000020e04cB|L11.188|
|L11.34|
;;;264sys_mbox_fetch(mbox,(void*)&msg);
0000224669MOVr1,sp
0000244827LDRr0,|L11.196|
0000261f00SUBSr0,r0,#4
0000286800LDRr0,[r0,#0];mbox
00002af7fffffeBLsys_mbox_fetch
;;;265switch(msg->type){
00002e9800LDRr0,[sp,#0]
0000307800LDRBr0,[r0,#0]
0000322805CMPr0,#5
000034d240BCS|L11.184|
000036e8dff000TBB[pc,r0]
00003a030bDCB0x03,0x0b
00003c222b3500DCB0x22,0x2b,0x35,0x00
;;;266#ifLWIP_NETCONN
;;;267caseTCPIP_MSG_API:
;;;268//if(msg->msg.apimsg->msg.conn==NULL)
;;;269//break;
;;;270LWIP_DEBUGF(TCPIP_DEBUG,("tcpip_thread:
APImessage%p\n",(void*)msg));
;;;271msg->msg.apimsg->function(&(msg->msg.apimsg->msg));
0000409a00LDRr2,[sp,#0]
0000426892LDRr2,[r2,#8]
0000441d10ADDSr0,r2,#4
0000469a00LDRr2,[sp,#0]
0000486892LDRr2,[r2,#8]
00004a6811LDRr1,[r2,#0]
00004c4788BLXr1
;;;272break;
00004ee034B|L11.186|//0x0801c7fb对应的代码
;;;273#endif/*LWIP_NETCONN*/
;;;274
;;;275caseTCPIP_MSG_INPKT:
;;;276LWIP_DEBUGF(TCPIP_DEBUG,("tcpip_thread:
PACKET%p\n",(void*)msg));
;;;277#ifLWIP_ARP
;;;278if(msg->if->flags&NETIF_FLAG_ETHARP){
0000509800LDRr0,[sp,#0]
从代码看地址对应是00004ee034B|L11.186|,即switch分支的break语句,但是实际应该是上面的那句,BLXr1,而此时R1的值是
R1=0x68130000,即跳转到68130000处执行,与在3.2的分析是一样的。
这也只能判断出出错的位置,原因还是需要仿真调试,才能找到。
3.4总结
发生HardFault以后,意味着程序跑飞了,有的原因是很简单的,但是有的需要仔细分析,以上两个例子应该都算比较简单的。
以第一个例子来说,若从首次定位来看是在中断里,中断里变量的数值太大,超出了外存的大小,但是这个值为什么会这么大?
正常中断接收数据不会变成有0x21FF2200这么多字节的,此时就需要考虑是别的地方踩到了此处的内存,导致取出来的数据一下子变成了这么大。
然后逐步定位,才能找出真正的原因。
4参考文献
网上有几篇非常不错的文章,可以看看,加深理解。
[1]Cortex-M3权威指南,JosephYiu著,宋岩译。
(在书的附录E中对Fault类异常有非常详尽的介绍)
[2]Cortex-M3技术参考手册,周立功。
(在书的P89到96页对以上所介绍的寄存器有很详细的描述)
[3]ApplicationNote209,UsingCortex-M3andCortex-M4FaultExceptions.KEILToolsbyARM.(这个是KEIL软件下使用的说明,介绍的例子可以一看)
[4]教你如何找到导致程序跑飞的指令,,