一.问题背景
量产的产品在品质抽检中出现设备概率无法正常使用的问题，经过初步定位确定是MCU上电未正常启动。
二.问题分析以及定位
在产品中考虑到MCU程序升级(RF SUB-1G升级，NB-IOT等无线升级方法)，因此采用的的是IAP升级架构
以STM32F103为例来说明，该型号MCU FLASH起始地址0x08000000，大小512KB即 0x00080000FLASH 的ERASE是2KB。
MCU的FLASH分区主要包括以下几个部分
概率无法启动可能的原因：
1)boot阶段异常，如启动流程卡住等；
2)boot阶段正常启动，但跳转到APP程序异常，如未跳转成功,此部分涉及CPU中断向量，中断设备，外设DMA设置等内容，需要重点检查 ;
3)boot阶段启动正常，boot跳转到app正常，app启动异常如启动流程卡住
1.复现问题方式
外接串口小板，通过不断的插拔电池，查看UART日志进行启动判断是否正常来复现问题 。这种方式比较考验体力
另外的自动化上下电启稳定性验证，即智能门锁设备+UART小板+电源控制工装，
其中电源控制工装,支持自定义设置上下电时间间隔，并支持UART特定单词监控，负责对智能门锁的上下电进行控制，并监控启动过程中打印，如正常启动的打印是app start ok，则代表当前启动成功，继续进行下电 上电启动验证，如在一定时间内未监控到app start ok，则代表当前启动异常，不进行下一次的上下电测试，保留现场，用于查看分析问题;
2.通过复现问题可定位是原因2，即boot阶段正常启动，但跳转到APP程序异常，未跳转成功,此部分涉及CPU中断向量，中断设备，外设DMA设置等内容，现有的启动跳转未对外设UART资源进行充分释放
三.解决问题及其方法原则
boot是一个可完全使用MCU资源的程序
app也是一完全使用MCU资源的程序
要求在boot跳转到app的时候，几个通用的程序处理流程;
1)boot程序正确设置跳转地址等相关信息 ，如下列参考代码
#define ApplicationAddress 0x8020000 //128KB
#define ApplicationSize 0x0030000
/* Jump to user application */
JumpAddress = *(__IO uint32_t*) (ApplicationAddress + 4);
printf("**********JUMP TO APP=0X%08X*********\r\n",JumpAddress);
Jump_To_Application = (pFunction) JumpAddress;
/* Initialize user application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) ApplicationAddress);
Jump_To_Application();
2）app程序正常映射FLASH的分区CPU及其外设资源 要充分释放干净，如UART的DMA通道要释放，DMA要停止运行，UART的中断要关闭
此部分是最容易被考虑不全忽略的，在此我们总结一个原则，原则上boot初始化用了哪些外设,如UART,DMA,中断等，跳转前均要做确认，是否需要释放
该部分操作在上述跳转代码前需要执行到位
3)app分区的相关地址空间设置以及代码连接文件正确
