大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是i.MXRT1024/1064片内4MB Flash的SFDP表易丢失导致的烧录异常。
我们知道 i.MXRT 系列本身并没有片内非易失性存储器作为启动设备，所以硬件工程师第一件事便是为 i.MXRT 搭配一颗外置代码存储器，而串行 NOR Flash 往往是代码存储器的第一选择。既然这是刚需，为何不直接合封一颗经典的 NOR Flash 进芯片内部呢？是的，恩智浦也考虑到了这一点，这便有了 i.MXRT1024/1064 这两颗内置 Flash 的型号（至于没有给 i.MXRT 全系列强制标配 NOR Flash，也跟代码存储器类型以及容量、速度需求不一有关）。
近期有一个 RT1064 客户反馈，在给产品做量产时出现芯片无法正常使用 J-Link 或者恩智浦官方下载工具下载程序到片内 Flash 的现象，恰好痞子衡手头有一块官方 RT1064-EVK 板卡也无法烧录程序，经过痞子衡的一番摸索，发现片内 Flash 竟然没有有效的 SFDP 表，这是怎么回事？且听痞子衡细说：
芯片合封技术实际上并不是什么新鲜事，对于 RT1024/1064 来说，就是将 RT1020/RT1060 的 Die 与选定的一颗 NOR Flash Die 封装在一起，RT 与 Flash 之间的信号连接在片内完成。
那么 RT1024/1064 内置的 NOR Flash 到底来自哪家供应商呢？这可以借助 \SDK_2_16_000_EVK-MIMXRT1064\boards\evkmimxrt1064\driver_examples\flexspi\nor_internal\polling_transfer 例程简单修改一下代码，读回 Flash 的 JEDEC ID 得知是来自全球排名第一的 NOR Flash 厂商 Winbond 的 W25Q32JV-IQ/JQ（4MB, 四线, 133MHz SDR，3.3V）。
在 RT1024 上使用了如下 PAD 连接到了片内 Flash，这些 PAD 同时也是外部引脚。（注意其中 GPIO_SD_B1_05 并没有被 BootROM 初始化，因为片内 Flash 不能直接高速启动）
- Note: GPIO_AD_B1[05:00] 虽说是外部引脚，但这些 PAD 对应的 PIN 功能被禁用了，可以理解为信号没有真正引出来，从而避免外部电路对片内 SIP flash 的干扰。
在 RT1064 上使用了如下 PAD 连接到了片内 Flash，这些 PAD 仅是内部引脚，没有引到外部。（不过在 BGA 225 封装的 RT1060X 型号上被引出了）
JESD216 是一个关于串行 NOR Flash 的标准，它“规范”了 NOR Flash 厂商的产品。这里的“规范”两字加了引号，因为这个标准比较有意思，并不是先有标准，再有 Flash 产品，而是先有各大厂商的 Flash 产品出来，然后 JESD216 才开始总结这些不同厂商的产品特性，企图形成一个看起来比较统一的规范。
目前主流 NOR Flash 厂商产品都是支持 JESD216 标准的，这体现在如下 Read SFDP (0x5A) 命令时序统一上。JESD216 标准定义了一个 256 字节大小的 SFDP 表，这个表收纳了该 Flash 的几乎全部特性（速度、容量、寄存器分布、命令集等等），对于软件驱动开发者来说尤其重要。
SFDP 表结构大概是这样，一开始是 signature 以及 version，然后是 Flash 各种属性信息。看到这你就能明白为啥 SFDP 对于烧录工具的重要性了，烧录工具依赖底层的 Flashloader，而 Flashloader 一般设计上是追求通用的，所以其会先获取 Flash SFDP 表进行解析得到 Flash 全部信息，然后根据这些信息加载合适的软件驱动去读写擦 Flash。因此如果得不到正确的 SFDP 表，那么依赖通用 Flashloader 的烧录工具便无法正常工作。J-Link 以及恩智浦官方烧录工具都是基于通用 Flashloader 思想设计的。
翻开以 W25Q32JV 为代表的 Winbond NOR Flash 数据手册，我们从其模块框图可以得知 Flash 内部存储颗粒由三种类型组成， 地址范围 0x000000 - 0x3FFFFF 的 Memory Block，地址范围 0x000000 - 0x0000FF 的 SFDP，地址范围 0x001000 - 0x0030FF 的 Security Registers。对于 Memory Block 的读写擦操作我们再熟悉不过了，那后两种类型该用什么命令操作呢？
继续查看数据手册，找到了如下关于 Security Registers 的专用读写擦命令时序。上一节介绍了 Read SFDP 命令，似乎 SFDP 这个地址空间仅支持读操作，那么 SFDP 数据是如何在 Flash 出厂时被写入的呢？到底是直接固化（随芯片 TO）？还是 OTP 一次性专用后门命令擦写的？带着这个疑惑，痞子衡咨询了 Winbond 技术人员，他们告知其实 Security Registers 擦写命令可以同样擦写 SFDP 空间。
即 Security Registers 读写擦命令时序里地址参数 A15-12 设 4'b0000 时，实际操作得就是 SFDP 空间（虽然手册里没有明说这一点）。基于这个消息，痞子衡找了一个正常的 RT1064-EVK 板卡读出其有效的 SFDP 表数据，然后将该 SFDP 表写入异常的 RT1064-EVK 板卡，这时候下载工具就能够正常烧录了。所以 RT1024/RT1064 芯片发生这种异常，要么是出厂漏烧了 SFDP 表，要么是 SFDP 被用户误擦除过。
至此，i.MXRT1024/1064片内4MB Flash的SFDP表易丢失导致的烧录异常痞子衡便介绍完毕了，掌声在哪里~~~
文章会同时发布到我的 博客园、CSDN、微信公众号、知乎、与非网、电子技术应用AET、电子星球、51CTO 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码，就可以在手机上第一时间看了哦。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。