在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元起步)再發。