大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是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型號支持，其實就是在 \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下載算法設計痞子衡便介紹完畢了，掌聲在哪里~~~
歡迎訂閱
文章會同時發布到我的 博客園主頁、CSDN主頁、知乎主頁、微信公眾號 平台上。
微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
