RM44 MCU（TI）的上电reset类型简析

最近在项目中添加了RM44的BootLoader功能，但其代码基础还是基于原本已有的裸机代码，其上电初始化和自诊断代码都保留了下来。

但在某次实验发现，使用TI的下载软件uniflash下载BootLoader+APP后，BootLoader相关打印连续出现了两次。但在正常上电时，却只有一次，这引起了我的注意。

因此经过调试，确认了问题所在，在本文章中稍作记录。

首先正常冷启动时，MCU的执行逻辑如下：

启动------>  检查resetreason   --->   (resetreason  = POWNON_RESET)

------>进行系统初始化------>进行CCM STC ----->MCU reset

------>启动------>  检查resetreason   --->   (resetreason  = STC_RESET) ------>检查成功 ------>继续进行其他自检和初始化 ------>进入mian

这个流程一个重要过程是在进行CCM STC后，MCU会自动reset一次，然后根据resetreason的不同走向不同分支。

而当我进行IAR仿真调试时，第一次启动的resetreason则变成了 DBUEG_RESET，此时不会进入CCM STC程序，而是直接开始其他诊断然后进入mian:

启动------>  检查resetreason   --->   (resetreason  = DBUEG_RESET)

------>进行系统初始化------>继续进行其他自检和初始化 ------>进入mian

最后一种情况即用uniflash下载，BootLoader会多一次进入的问题：

启动------>  检查resetreason   --->   (resetreason  = DBUEG_RESET & EXTERNAL_RESET)

------>进行系统初始化继续进行其他自检和初始化 ------>进入mian------>运行BootLoader

------>运行APP------>检查resetreason ------>  (resetreason  = EXTERNAL_RESET)

------>进行CCM STC ----->MCU reset------>再次返回BootLoader入口

这里就能看出，BootLoader运行了两次的原因，进入APP时CCM STC检查使整个系统reset，再次进入了BootLoader，然后BootLoader把resetreason再次清除后，APP获取不到resetreason，则按照默认的DEBUG_RESET方式运行，进入APP MAIN.

此问题最主要的原因是uniflash触发的DEBUG_RESET还会连带拉低nRST引脚，使EXTERNAL_RESET也置位，而软件上没有同时清除两个标志位导致的。

修改从两个方面入手：1：在resetreason获取后要清除所有标志位。2：调整BootLoader和APP的上电诊断步骤，使只有一个诊断。

当然两者一起是最好的。目前暂时采用1方案，等有空再慢慢梳理方案2,。