大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是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主頁、知乎主頁、微信公眾號 平臺上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
