IDE::IAR
芯片:STM32XXX
操作系统:RTOS(MICO)
复位是一个很普遍很让人头疼的事情，大多数复位的原因是数组越界、堆栈溢出导致程序跑飞，最后看门狗复位了程序。难点就是因为复位了，所以没办法定位到是哪里导致的复位。很多时候单步运行也找不到复位的点，有时候定位到的会是一条人畜无害的语句，注释了就不复位了，这种情况其实就是没找到真正的bug。
这一篇文章的目标是确定复位的类型，定位导致程序复位的代码段。
1 确定复位类型
虽然确定复位类型没什么很大的用途，但是至少能提供一些方向性的东西。
把以下函数添加到主程序中：
/*
RCC_FLAG_BORRST: POR/PDR or BOR reset //Power-on/power-down reset (POR/PDR reset) or brownout (BOR) reset
RCC_FLAG_PINRST: Pin reset
RCC_FLAG_PORRST: POR/PDR reset
RCC_FLAG_SFTRST: Software reset
RCC_FLAG_IWDGRST: Independent Watchdog reset
RCC_FLAG_WWDGRST: Window Watchdog reset
RCC_FLAG_LPWRRST: Low Power reset
*/
u8 reset_temp[7];
void SysRstSrcRecord(u8 *pstRest)
{
pstRest[0] = RCC_GetFlagStatus(RCC_FLAG_BORRST);
pstRest[1] = RCC_GetFlagStatus(RCC_FLAG_PINRST);
pstRest[2] = RCC_GetFlagStatus(RCC_FLAG_PORRST);
pstRest[3] = RCC_GetFlagStatus(RCC_FLAG_SFTRST);
pstRest[4] = RCC_GetFlagStatus(RCC_FLAG_IWDGRST);
pstRest[5] = RCC_GetFlagStatus(RCC_FLAG_WWDGRST);
pstRest[6] = RCC_GetFlagStatus(RCC_FLAG_LPWRRST);
}
然后在主函数的开头调用该函数（主线程开头也可以）：
SysRstSrcRecord(reset_temp);
这里要注意的是reset_temp要定义成全局变量，由于我所有串口都占用了不能输出调试信息，所以要定义成全局变量，使用IDE查看变量的值。
在IAR上选择view—live watch，把reset_temp添加在里面：
live watch
程序复位之后，就可以确定复位的类型了。可以在主函数的开头加一个断点，程序复位的时候就能立刻看出来了。
2 查找复位源头
这里以hardfault为例，其他类型的复位可以也参考。
首先找到hard_fault_handler函数（基本大都是这个函数名，会略有区别），在函数开头打上断点。程序复位后到了这个地方，再往前查找几步就能大概确定原因了。找不到这个函数的话可以试一下关掉看门狗，程序会死在这个函数的while循环里。
程序断点到这里之后，在iar里点击View---Register打开Register窗口，复制下来SP寄存器的值：
SP
再点击View---Memory，把SP的值复制到Go to中进行查找（点击右边的小箭头，选择4x Units，四个一组，方便看）：
memory
查找后找到指定地址内的内容，因为程序大多是从0x08000000开始的，所以就找到附近一两行的0x08开头的，记下来：
08.png
点击iar的view--Disassembly，打开Disassembly窗口，把记下来的0x08开头的地址复制进来查找：
0x08xxxx
查找到的就是复位前在执行的内容，基本上在这段程序附近看看就有解决的灵感了。需要注意的是这不意味着这段程序有问题，很可能这段程序是底层，是你的程序调用它的时候导致了别的错误。就比如用法错误导致内存溢出等等。
下一篇就是关于堆栈溢出的。
