在i.MXRT硬件那些事系列之《在串行NOR Flash XIP调试原理》一文中，痞子衡简单提了一下串行NOR Flash下载算法的概念，并没有介绍具体设计细节，关于NOR Flash下载算法每个IDE/工具都有自己的一套设计，虽然基本设计理念是一样的，但是细节方面还是有区别，今天痞子衡就来细聊J-Link下的NOR Flash下载算法
大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是J-Link工具下i.MXRT的串行NOR Flash下载算法设计。
在i.MXRT硬件那些事系列之《在串行NOR Flash XIP调试原理》一文中，痞子衡简单提了一下串行NOR Flash下载算法的概念，并没有介绍具体设计细节，关于NOR Flash下载算法每个IDE/工具都有自己的一套设计，虽然基本设计理念是一样的，但是细节方面还是有区别，今天痞子衡就来细聊J-Link下的NOR Flash下载算法：
从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的正式发布。
关于增加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 型号为例：
模板代码中参数主要分两类：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。
前面讲了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驱动版本更新时的记录得知其动态，但总觉得是个黑盒子。
下一篇文章，痞子衡将带大家深入探究Keil MDK下的下载算法设计，了解了这个MDK下载算法，我们便可以自己为J-Link设计下载算法，从此再也不用担心黑盒子。
至此，J-Link工具下i.MXRT的串行NOR Flash下载算法设计痞子衡便介绍完毕了，掌声在哪里~~~
文章会同时发布到我的 博客园主页、CSDN主页、知乎主页、微信公众号 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码，就可以在手机上第一时间看了哦。
最后欢迎关注痞子衡个人微信公众号【痞子衡嵌入式】，一个专注嵌入式技术的公众号，跟着痞子衡一起玩转嵌入式。
衡杰(痞子衡)，目前就职于恩智浦MCU系统部门，担任嵌入式系统应用工程师。
专栏内所有文章的转载请注明出处：http://www.cnblogs.com/henjay724/
与痞子衡进一步交流或咨询业务合作请发邮件至 [email protected]
可以关注痞子衡的Github主页 https://github.com/JayHeng，有很多好玩的嵌入式项目。
关于专栏文章有任何疑问请直接在博客下面留言，痞子衡会及时回复免费(划重点)答疑。
痞子衡邮箱已被私信挤爆，技术问题不推荐私信，坚持私信请先扫码付款(5元起步)再发。