痞子衡嵌入式：记录为i.MXRT1060更换较大容量Flash(IS25LP064A_IS25LP128F)导致二级App异常启动问题解决全过程(上篇)

　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家分享的是为i.MXRT1060更换较大容量Flash导致二级App异常启动问题。

　　痞子衡最近在支持一个 RT1062 国外客户项目，客户在项目预研阶段为 RT1062 搭配的启动 Flash 是较小容量 IS25LP064A，接近量产的时候需要改用较大容量 IS25LP128F。客户本以为只是一个简单的同厂家同系列 Flash 容量小升级而已，谁知道竟然遇到奇怪的芯片启动问题！在痞子衡和客户一番沟通之后，认定确实是个非常奇怪的案例，且听痞子衡慢慢道来：

　　本篇是上篇，主要是抛出问题，希望大家能够留言积极回复，给出你认为出问题的地方。

一、问题描述

　　客户项目代码分为两个部分，一个是从 0x6000_2000 处开始链接的 L2 Boot，还有一个是 0x6040_0000 处开始链接的 App，RT1062 芯片上电 BootROM 加载 L2 Boot 运行，L2 Boot 再跳转到 App 执行。

　　客户首先在小容量 IS25LP064A 上通过了代码测试，借助恩智浦官方下载工具 MCUXpresso SEC Secure Provisioning Tool (当然这里痞子衡更推荐的是 NXP-MCUBootUtility)，先烧写 App，再烧写 L2 Boot（因为 App 由 L2 Boot 直接引导执行，所以其无需 RT 启动头，即使后下载的 L2 Boot 启动头会覆盖先下载的 App 启动头也无关紧要）。

　　客户最终希望能给 L2 boot 做签名启动，App 无需签名，所以 RT1062 内部 fuse SEC_CONFIG[1:0] 需要被烧写成 2'b1x - HAB Closed。客户同时做了两种测试，L2 boot 无签名情况以及有签名情况，均正常工作，因此可以证明当前 L2 Boot 和 App 代码设计在 IS25LP064A 上跑一切正常，也和是否签名无关（RT1062 HAB 状态）。

　　然后客户换了一块新板子，上面放置得是大容量 IS25LP128F，程序无任何改动，下载流程也一样，在 L2 Boot 无签名的时候，也能够正常工作。但是一旦给 L2 Boot 加了签名，这时候 L2 Boot 能够正常启动（有 Log 打出），但是 App 却没有正常启动（无 Log 输出），并且从 Log 输出来看，L2 Boot 一直在重复启动。

　　看到这你的第一反应是什么？根据控制变量法，似乎问题是由换到 IS25LP128F 引起的，也似乎是 L2 Boot 加了签名引起的。但是客户之前的测试能够证明，单独改动这两个 X 因素之一并不会导致问题，然而合在一起就引发了问题。

二、现有测试与分析

　　目前客户暂未分享其项目代码给痞子衡，为了快速验证客户这种情况，痞子衡在恩智浦开发板 RT1060-EVKC 上做了类似测试，在 \SDK_24_12_00_MIMXRT1060-EVKC\boards\evkcmimxrt1060\demo_apps\hello_world 例程基础上（flexspi_nor_debug）上创建了两个 target，一个是 flexspi_nor_boot（增加 app 跳转代码），另一个 flexspi_nor_app（去掉 BOOT_HEADER，然后修改链接地址到 0x6040_0000）。

测试代码地址： https://github.com/JayHeng/func-rt1060-flexspi-minimal-boot-and-app

　　分别编译出 Mini L2 Boot 和 Mini App 之后，按照客户同样下载流程（用 SEC 上位机，且使能签名），这是痞子衡第一次用官方 SEC 上位机做签名下载操作，使用体验总体不如 NXP-MCUBootUtility 来得顺手。

　　痞子衡先在默认 W25Q128JWSIQ 上做了测试，然后又将板子上的 Flash 换成了 IS25LP128F 做了同样测试。让痞子衡感到遗憾的是，并未复现客户的情况，Mini L2 Boot 和 Mini App 跑得稳如狗。

三、值得关注的点

　　虽然没能成功复现客户的问题，但是在检查客户使用的两颗 Flash 的数据手册时，还是发现了一些隐患点的。我们先来看一下恩智浦官方开发板 Flash 使用情况以及 SDK 里对 Flash XIP 启动的速度配置（所谓 FCB，\SDK_XXX_MIMXRT1xxx-EVK\boards\evkmimxrt1xxx\xip\evkmimxrt1xxx_flexspi_nor_config.c），从 SDK 2.15 开始 FCB 尝试为支持调整 dummy cycle 的 Flash 做了适配以跑到 Flash 的最高速度。

Note：不了解 dummy cycle 可以先阅读痞子衡旧文《在i.MXRT启动头FDCB里调整Flash工作频率也需同步设Dummy Cycle (以IS25WP128为例)》

　　然而在 RT1060 SDK 里的 FCB 并没有加入 dummy cycle 方面的考虑，直接就是用了默认 6 dummy cycle 来支持 120MHz SDR Quad Fast Read (0xEB) 性能，这对于 RT1060-EVK/EVKB 上的 IS25WP064AJBLE 来说其实是有隐患的（对应默认最高频率是 104MHz），算超频在跑了。

　　此外痞子衡旧文《同一厂商不同系列Flash型号下Dummy Cycle设置方法可能有差异 (以IS25LP064A为例)》里介绍了 IS25LP064A 和 IS25WP128 系列有差异，用相同的分析方法你会发现 IS25LP064A 和 IS25LP128F 一样有差异，虽然 IS25LP128F 上限可以跑到 166MHz，但是默认 6 dummy cycle 下仅支持 81MHz。

　　客户包括痞子衡都直接使用得 SEC 上位机工具自动生成的 FCB 头，其只能使用默认 6 dummy cycle，而我们都将 Flash 运行频率设到了 120MHz 以上，这显然是有隐患的（虽然痞子衡的 Mini L2 Boot/App 没有跑出问题，但是压力运行之下可靠性无法保证）。

　　这会是客户问题的答案吗？痞子衡让客户将 Flash 工作频率调到了 80MHz 以符合手册要求，但是客户反馈，问题仍然存在！目前为止，痞子衡暂无其它思路，你能想到可能出问题的地方吗？

欢迎订阅

文章会同时发布到我的博客园、CSDN、微信公众号、知乎、与非网、电子技术应用AET、电子星球、51CTO 平台上。

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