1 解莫名其妙的复位

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

查找到的就是复位前在执行的内容，基本上在这段程序附近看看就有解决的灵感了。需要注意的是这不意味着这段程序有问题，很可能这段程序是底层，是你的程序调用它的时候导致了别的错误。就比如用法错误导致内存溢出等等。
下一篇就是关于堆栈溢出的。