J-Link下i.MXRT的串行NOR Flash下載算法設計

大家好，我是痞子衡，是正經(jīng)搞技術的痞子。今天痞子衡給大家介紹的是 J-Link 工具下 i.MXRT 的串行 NOR Flash 下載算法設計。

?

一、J-Link 各版本對 i.MXRT 的支持

從 Segger 官網(wǎng)上看，目前最新的 J-Link 驅(qū)動版本是 V6.86b，其能夠支持目前所有已量產(chǎn)的 i.MXRT 系列，而痞子衡 PC 上安裝的是 V6.52e，從 J-Link 歷史各版本 Release Note 上看，痞子衡目前的 J-Link 版本不支持全部 i.MXRT 型號，那么如果想要支持新芯片（比如 i.MXRT1170），是不是一定要重新安裝最新 J-Link 呢？其實未必！

?

J-Link 對新 MCU 型號的下載支持并不是與自身版本嚴格綁定的，其增加新芯片的方式很靈活，只需要按要求添加相應的算法文件即可，這樣我們可以不必等待 Segger 的正式發(fā)布。

?

二、為當前 J-Link 增加新 i.MXRT 型號支持

關于增加 i.MXRT 新型號的支持，痞子衡之前寫過一篇文章?《輕松為 i.MXRT 設計更新 Segger J-Link Flash 下載算法文件》，簡介了如何為 v.6.52e 版本新增 i.MXRT600 的支持（那篇文章其實有點疏忽，v6.52 版本已經(jīng)開始支持 i.MXRT600，直接集成進 JLinkARM.dll 中了，沒有顯式地放在 JLinkDevices.xml 文件中）。

?

為當前 J-Link 驅(qū)動增加新 i.MXRT 型號支持，其實就是在 SEGGERJLink_V652eJLinkDevices.xml 文件中按模板添加一些代碼，至于那些代碼是什么含義，在 SEGGERJLink_V652eDocManualsUM08001_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>

?

模板代碼中參數(shù)主要分兩類：ChipInfo 和 FlashBankInfo，前者描述算法適用的 MCU 芯片相關信息，后者描述在該 MCU 上適用的 Flash 操作相關信息。

?

先說 ChipInfo 下的參數(shù)：Vendor 和 Name 主要是創(chuàng)建 J-Flash 工程或者在 IDE 里在線下載時彈出 J-Link 選項框時用于確定選擇這個下載算法文件的標識。Core 用于指定 MCU 芯片內(nèi)核類型。JLinkScriptFile 指定開始啟用下載算法前需預加載的 Jlink 腳本（可以根據(jù) MCU 特性做一些特殊的初始化工作，比如 RT600 的 Debug Mailbox 激活，RT1170 的雙核切換等）。Aliases 就是 Name 的詳細展開。

?

ChipInfo 下最重要的兩個參數(shù)其實是 WorkRAMAddr 和 WorkRAMSize，它們指明了下載算法(某種 elf 格式文件)被加載進 MCU 內(nèi)部 SRAM 執(zhí)行的區(qū)域，這兩個參數(shù)值與 MCU 型號息息相關，必須是合法有效的，但可以不唯一。后面的文章里痞子衡會介紹下載算法設計原理，其最重要的特性是 Read-Only Position Independent 和 Read-Write Position Independent，即下載算法本身不是固定地址鏈接，而是位置無關鏈接，算法代碼機器碼是可以被放到任意地址去執(zhí)行的。

?

再說 FlashBankInfo 下的參數(shù)：Name 標明下載算法適用的 Flash 類型（FlashBankInfo 可以有多個，對應不同 Flash 的下載算法）。BaseAddr 和 MaxSize 標明該 Flash 在 MCU 系統(tǒng)內(nèi)存映射中的地址范圍，主要用于后續(xù) XIP 調(diào)試，跟下載關系不大。Loader 和 LoaderType 則指明下載算法文件位置和類型，這是核心，對于新 i.MXRT 型號的下載支持，大部分工作其實就是提供合適的 Loader。

三、NOR Flash 下載算法設計

前面講了 J-Link 對于新 i.MXRT 型號的下載支持，其實就是提供合適的 Loader 文件，Loader 文件的設計是核心，那么 J-Link 的 Loader 到底是怎么設計的呢？這得先從理解 LoaderType 這個參數(shù)說起。

?

搜遍整個 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 兩者的下載算法文件基本是可以交換使用的（當然設計上有一點小區(qū)別，后面文章會介紹）。

鑒于 Segger 并沒有開源其下載算法源碼，因此我們無法得知其 J-Link 自帶的下載算法文件具體是怎么實現(xiàn)（例如 Devices/NXP/iMXRT106x/NXP_iMXRT106x_QSPI.elf），雖然我們可以根據(jù)每次的 J-Link 驅(qū)動版本更新時的記錄得知其動態(tài)，但總覺得是個黑盒子。

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 下載算法設計痞子衡便介紹完畢了，掌聲在哪里~~~