大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家介绍的是 J-Link 工具下 i.MXRT 的串行 NOR Flash 下载算法设计。
一、J-Link 各版本对 i.MXRT 的支持
从 Segger 官网上看,目前最新的 J-Link 驱动版本是 V6.86b,其能够支持目前所有已量产的 i.MXRT 系列,而痞子衡 PC 上安装的是 V6.52e,从 J-Link 历史各版本 Release Note 上看,痞子衡目前的 J-Link 版本不支持全部 i.MXRT 型号,那么如果想要支持新芯片(比如 i.MXRT1170),是不是一定要重新安装最新 J-Link 呢?其实未必!
版本 | 发布时间 | 支持芯片 |
---|---|---|
V6.84 | 2020-09-04 | i.MXRT1024 |
V6.64 | 2020-03-13 | i.MXRT1170 |
V6.60 | 2019-12-16 | i.MXRT1010 |
V6.46 | 2019-05-23 | i.MXRT500、i.MXRT600 |
V6.44 | 2019-03-01 | i.MXRT1015 |
V6.40 | 2018-10-26 | i.MXRT1064 |
V6.34 | 2018-08-07 | i.MXRT1060 |
V6.32 | 2018-04-20 | i.MXRT1050、i.MXRT1020 |
J-Link 对新 MCU 型号的下载支持并不是与自身版本严格绑定的,其增加新芯片的方式很灵活,只需要按要求添加相应的算法文件即可,这样我们可以不必等待 Segger 的正式发布。
二、为当前 J-Link 增加新 i.MXRT 型号支持
关于增加 i.MXRT 新型号的支持,痞子衡之前写过一篇文章 《轻松为 i.MXRT 设计更新 Segger J-Link Flash 下载算法文件》,简介了如何为 v.6.52e 版本新增 i.MXRT600 的支持(那篇文章其实有点疏忽,v6.52 版本已经开始支持 i.MXRT600,直接集成进 JLinkARM.dll 中了,没有显式地放在 JLinkDevices.xml 文件中)。
为当前 J-Link 驱动增加新 i.MXRT 型号支持,其实就是在 \SEGGER\JLink_V652e\JLinkDevices.xml 文件中按模板添加一些代码,至于那些代码是什么含义,在 \SEGGER\JLink_V652e\Doc\Manuals\UM08001_JLink.pdf 文档的 Chapter 12 Open Flashloader有详细解释。
让我们试着分析 JLinkDevices.xml 文件中那些模板代码的含义,且以最常见的 i.MXRT1060 型号为例:
<Device>
<ChipInfo Vendor="NXP"
Name="MIMXRT1062xxx6A"
WorkRAMAddr="0x20000000"
WorkRAMSize="0x00080000"
Core="JLINK_CORE_CORTEX_M7"
JLinkScriptFile="Devices/NXP/iMXRT106x/NXP_iMXRT106x.pex"
Aliases="MIMXRT1062DVL6A" />
<FlashBankInfo Name="QSPI Flash"
BaseAddr="0x60000000"
MaxSize="0x04000000"
Loader="Devices/NXP/iMXRT106x/NXP_iMXRT106x_QSPI.elf"
LoaderType="FLASH_ALGO_TYPE_OPEN" />
</Device>
模板代码中参数主要分两类:ChipInfo 和 FlashBankInfo,前者描述算法适用的 MCU 芯片相关信息,后者描述在该 MCU 上适用的 Flash 操作相关信息。
先说 ChipInfo 下的参数:Vendor 和 Name 主要是创建 J-Flash 工程或者在 IDE 里在线下载时弹出 J-Link 选项框时用于确定选择这个下载算法文件的标识。Core 用于指定 MCU 芯片内核类型。JLinkScriptFile 指定开始启用下载算法前需预加载的 Jlink 脚本(可以根据 MCU 特性做一些特殊的初始化工作,比如 RT600 的 Debug Mailbox 激活,RT1170 的双核切换等)。Aliases 就是 Name 的详细展开。
ChipInfo 下最重要的两个参数其实是 WorkRAMAddr 和 WorkRAMSize,它们指明了下载算法(某种 elf 格式文件)被加载进 MCU 内部 SRAM 执行的区域,这两个参数值与 MCU 型号息息相关,必须是合法有效的,但可以不唯一。后面的文章里痞子衡会介绍下载算法设计原理,其最重要的特性是 Read-Only Position Independent 和 Read-Write Position Independent,即下载算法本身不是固定地址链接,而是位置无关链接,算法代码机器码是可以被放到任意地址去执行的。
再说 FlashBankInfo 下的参数:Name 标明下载算法适用的 Flash 类型(FlashBankInfo 可以有多个,对应不同 Flash 的下载算法)。BaseAddr 和 MaxSize 标明该 Flash 在 MCU 系统内存映射中的地址范围,主要用于后续 XIP 调试,跟下载关系不大。Loader 和 LoaderType 则指明下载算法文件位置和类型,这是核心,对于新 i.MXRT 型号的下载支持,大部分工作其实就是提供合适的 Loader。
三、NOR Flash 下载算法设计
前面讲了 J-Link 对于新 i.MXRT 型号的下载支持,其实就是提供合适的 Loader 文件,Loader 文件的设计是核心,那么 J-Link 的 Loader 到底是怎么设计的呢?这得先从理解 LoaderType 这个参数说起。
搜遍整个 UM08001_JLink 文档,LoaderType 仅有一个值,即 FLASH_ALGO_TYPE_OPEN,文档里的解释是使用公开的 Flashloader 算法设计,这个公开的 Flashloader 指的是 ARM 官方的基于 CMSIS 的 Flashloader。
ARM 开源的 Flashloader 算法属于 CMSIS-Pack 中的 Device Family Pack (DFP) 里的一个组成部分,它本来是专用于 Keil MDK 下的,但是 Segger 为了保持其 J-Link 工具链的通用性,选择了与 ARM Flashloader 的 API 接口保持一致,这意味着 Keil MDK 与 J-Link 两者的下载算法文件基本是可以交换使用的(当然设计上有一点小区别,后面文章会介绍)。
鉴于 Segger 并没有开源其下载算法源码,因此我们无法得知其 J-Link 自带的下载算法文件具体是怎么实现(例如 Devices/NXP/iMXRT106x/NXP_iMXRT106x_QSPI.elf),虽然我们可以根据每次的 J-Link 驱动版本更新时的记录得知其动态,但总觉得是个黑盒子。
Version V6.80d
DLL 3.NXP RT106x: Flash programming >= 8 MB failed. Fixed.
Version V6.80c
DLL 1.NXP RT106x: QSPI programming failed under specific circumstances. Fixed.
Version V6.70
DLL 19.NXP RT106x: QSPI programming did not work for some already supported flashes. Fixed.
Version V6.62b
DLL 9.NXP iMXRT106x: (Q)SPI flash programming did not work when using Adesto ATXP064 as external flash. Fixed.
Version V6.60
DLL 1.Added flash programming support for NXP MIMXRT1062DVJ6A (QSPI flash).
Version V6.40b
DLL 4.Fixed clock restore settings within programming algorithms for iMXRT105x and iMXRT106x QSPI-FLASH and HyperFLASH series devices.
Version V6.34
DLL 8.Added QSPI-Flash programming support for NXP i.MX RT106x series devices.
下一篇文章,痞子衡将带大家深入探究 Keil MDK 下的下载算法设计,了解了这个 MDK 下载算法,我们便可以自己为 J-Link 设计下载算法,从此再也不用担心黑盒子。
至此,J-Link 工具下 i.MXRT 的串行 NOR Flash 下载算法设计痞子衡便介绍完毕了,掌声在哪里~~~