大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是i.MXRT1xxx在Hab关闭时出现偶发性启动失败原因分析。

　　最近有一个 RT1064 客户（无人机产品）遇到了一个奇怪的启动失败问题，客户应用程序设计里需要使用软件复位来重新启动（涉及 OTA 功能升级程序），重新软复位启动会有万分之几的失败概率。

　　咋一看，很容易让人联想到这个问题可能和 OTA 功能设计缺陷有关，比如在 OTA 尚未结束的时候就误触发软件复位，此时 Flash 操作还在进行中，当然不能被 CPU 正常被访问从而导致 ROM 启动失败。

　　然而，客户又进一步补充了一个现象，当挂上 J-Link 调试器做相同测试时，失败概率从万分之几一下子提升到 10%（真实性有待考察），这个就比较有意思了。 进一步询问得知，客户烧写了 RT1064 的 HAB，将其变成了 Closed 状态，也就是使能签名启动。初步判断，问题应该和 OTA 关系不大，大概率是和 HAB 关闭引入的系统安全检查规则有关，今天我们就来聊一下这个话题：

• Note1: 本文适用全部的 RT10xx 和 RT1160/1170，但不一定适用 RT1180。
• Note2: RT10xx （HAB v4.3） 和 RT1160/1170（HAB v4.5.5） 内部安全管理系统属于第一代 HAB。
• Note3: RT1180 启用了全新安全管理系统架构 AHAB。

一、检查ROM启动日志

　　在分析问题前，先简单聊一下 HAB 设置，RT1064 HAB 一共三种状态（由 efuse 里的 SEC_CONFIG[1] 和 SEC_CONFIG[0] 位共同决定），其中 Closed 状态代表使能芯片严格安全检查机制。

2'b00 - FAB (Open)
2'b01 - Open (allows any code to be flashed and executed, even if it has no valid signature.)
2'b1x - Closed (Security On)

　　当客户启动失败问题发生的时候，我们可以通过《检查 ROM 启动日志》来初步确认问题范围，下面是从客户板子上获取到的 log 信息，从信息里看明明启动模式是 2'b10 - internal，但是它竟然直接就进入 SDP 模式了，这很异常，完全没有看到对于 boot device 的处理过程，这也进一步论证了问题和 Flash 无关。

.--------------------------------------------------------------------------------------------
| Log Entry  |          Description                                                        |
.--------------------------------------------------------------------------------------------
 0x00010002:  BOOTMODE_INTERNAL
 0x000200cc:  SEC_CONFIG_CLOSED
 0x00030001:  DIR_BT_DIS_VALUE1
 0x00040001:  BT_FUSE_SEL_VALUE1
 0x000c0000:  SDP_ENTRY

　　作为对比，我们看一下当启动模式是 2'b10 - internal 时（痞子衡用得是官方 EVK，并未烧写 HAB），但 Flash 为空导致启动失败情况的 log，这里我们能看到 PRIM_IMAGE_SELECT、PRIM_BOOTDEVICE_FLEXSPI_NOR 等信息，表明 ROM 有尝试获取 Flash 内容的动作，这才是正常的行为。

.--------------------------------------------------------------------------------------------
| Log Entry  |          Description                                                        |
.--------------------------------------------------------------------------------------------
0x00010002:  BOOTMODE_INTERNAL
0x000200f0:  SEC_CONFIG_OPEN
0x00030001:  DIR_BT_DIS_VALUE1
0x00040000:  BT_FUSE_SEL_VALUE0
0x00050000:  PRIM_IMAGE_SELECT
0x00060008:  PRIM_BOOTDEVICE_FLEXSPI_NOR
0x00070000:  DEVICE_INIT_CALL
0x000700f0:  DEVICE_INIT_PASS
0x00090000:  AUTHENTICATION_STATUS

二、检查JTAG电路

　　由于 RT1064 芯片里的安全系统是个黑盒子，从文档里找不到注意事项。痞子衡和负责安全的专家聊了一下，专家认为这个问题是芯片内部 SNVS 硬件先于 ROM 执行前检测到了 JTAG 电路有异常导致误触发了 security event，比如 JTAG_TRSTB 或者 JTAG_TCK 等引脚上出现 glitch，从这个角度来解释，倒是能和万分之几的失败概率对得上。

　　痞子衡查看了一下 RT1050_1060 硬件设计指南里关于 JTAG 电路的设计注意事项，这里强调了当切换调试接口协议从默认 SWD 换到 JTAG 时，建议量产阶段给 JTAG_TRSTB 引脚加上 4.7K 欧姆的下拉。

　　于是我们便让客户检查 JTAG 电路设计，得知客户用得是默认 SWD 协议，且 GPIO_AD_B0_11（JTAG_TRSTB） 用于了一般应用功能，无外部上下拉电阻。这里需要注意，即使走得是 SWD 协议，复位期间 JTAG_TRSTB 等信号出现 glitch 仍然有可能触发安全隐患（仅在 HAB closed 状态下会导致问题）。GPIO_AD_B0_07（JTAG_TCK）也是处于悬空状态，最好给这些引脚加上外部下拉（仅靠芯片内部 100K 欧姆弱下拉不一定够），降低风险（后经客户工程师确认，TCK 加外部下拉方法有效）。

　　在硬件设计灵活性这一块，那还得看官方 EVK 设计，上下拉选项都预留了。

　　至此，i.MXRT1xxx在Hab关闭时出现偶发性启动失败原因分析痞子衡便介绍完毕了，掌声在哪里~~~

欢迎订阅

文章会同时发布到我的 博客园主页、CSDN主页、微信公众号 平台上。

微信搜索"痞子衡嵌入式"或者扫描下面二维码，就可以在手机上第一时间看了哦。