大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是J-Link工具下i.MXRT的串行NOR Flash下载算法设计。
在i.MXRT硬件那些事系列之《在串行NOR Flash XIP调试原理》一文中，痞子衡简单提了一下串行NOR Flash下载算法的概念，并没有介绍具体设计细节，关于NOR Flash下载算法每个IDE/工具都有自己的一套设计，虽然基本设计理念是一样的，但是细节方面还是有区别，今天痞子衡就来细聊J-Link下的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型号支持，其实就是在 SEGGERJLink_V652eJLinkDevices.xml 文件中按模板添加一些代码，至于那些代码是什么含义，在 SEGGERJLink_V652eDocManualsUM08001_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下载算法设计痞子衡便介绍完毕了，掌声在哪里~~~
欢迎订阅
文章会同时发布到我的 博客园主页、CSDN主页、知乎主页、微信公众号 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码，就可以在手机上第一时间看了哦。
