痞子衡嵌入式：恩智浦i.MX RT1xxx系列MCU硬體那些事（2.3）- 串行NOR Flash下載演算法(J-Link工具篇)

　　大家好，我是痞子衡，是正經搞技術的痞子，今天痞子衡給大家介紹的是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呢？其實未必！

　　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主頁、知乎主頁、微信公眾號 平臺上，

微信搜索"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦，

標籤：嵌入式

上一篇：Linux系統編程 —時序競態

下一篇：Linux系統編程 —時序競態