分散鏈接與加載一直是嵌入式領域比較勸退新手的難題，在恩智浦i.MX RT系列為代表的多存儲器架構的MCU上，分散鏈接問題體現得尤為明顯，畢竟你在鏈接應用程序各種段(section)時可能會面對包括內部ITCM/DTCM/OCRAM和外部 Flash/SDRAM/PSRAM/HyperRAM等多種存儲器空間選擇。

我們再進一步描述客戶工程分散鏈接問題，下圖包含了i.MX RT架構下程序段的全部鏈接選擇，根據這些選擇組合，我們能產生多種不同的工程鏈接文件。

先來看不涉及分散鏈接的簡單情況，即readonly段全在Flash里，readwrite段在一個或多個RAM空間里，這種情況下IAR下載調試沒有什么特殊注意事項，flashloader會負責外部Flash初始化，并將readonly段數據下載進Flash，然后宏文件負責外部RAM初始化，在線調試一切正常。

Case1：APP readonly text/data1 + APP readwrite data2/3/4

再來看第二種情況，這里開始涉及分散鏈接，readonly段分散在多個RAM空間，readwrite段在一個或多個RAM空間里。這種情況下因為沒有鏈接在Flash空間，因此無需flashloader，完全由宏文件將相關外部RAM初始化好，多個readonly段都能正常下載，在線調試一切正常。

Case2：APP readonly text/data2/3/4 + APP readonly text/data2/3/4 + APP readwritedata2/3/4

第三種情況再復雜一點，readonly段除了在Flash空間外，還有一部分放在了內部RAM里，然后readwrite段依然在一個或多個RAM空間里。這種情況下IAR下載調試感覺上應該沒問題，因為內部RAM無需初始化可直接訪問，兩個不連續readonly段原則上可以下載，但是很遺憾，IAR會報錯，其flashloader無法處理放在內部RAM的readonly段，調試無法進行。

Case3：APP readonly text/data1 + APP readonly text/data2 + APP readwrite data2/3/4

最后一種分散鏈接的情況最復雜，也是客戶的問題所在，readonly段除了在Flash空間外，還有一部分放在了外部RAM，然后readwrite段在一個或多個RAM空間里。這種情況下IAR下載調試一定會出問題，默認flashloader只做了Flash初始化，并不負責初始化外部RAM，因此部分readonly段往外部RAM下載時會報錯，工程宏文件雖然負責初始化外部RAM，但其執行階段在flashloader作用之后，鞭長莫及。

Case4：APP readonly text/data1 + APP readonly text/data3/4 + APP readwrite data2/3/4

我們在恩智浦官方MIMXRT1060-EVK板上復現一下客戶問題，使用SDK_2.11.0_EVK-MIMXRT1060oardsevkmimxrt1060demo_appshello_worldiar工程，原工程有很多Build，我們就選用flexspi_nor_sdram build，它用到了兩塊外部存儲器，符合客戶場景。

在這個build里readonly段都鏈在外部Flash里，readwrite段都鏈接在外部SDRAM里，顯然這個情況屬于第一節介紹的case1：

1. Flash初始化工作：IARSystemsEmbedded Workbench9.10.2armconfigflashloaderNXPFlashIMXRT1060_FlexSPI.out

2. SDRAM初始化工作：SDK_2.11.0_EVK-MIMXRT1060oardsevkmimxrt1060demo_appshello_worldiarevkmimxrt1060_sdram_init.mac

我們現在要將工程稍微改動一下，在工程源文件里定義一個sw_delay()函數（記得要在main函數里調用一下），并且將其指定在自定義.sdramCodeSection段里：

#pragma default_function_attributes = @ ".sdramCodeSection"
void sw_delay(void)
{
     __NOP();
}
#pragma default_function_attributes =

然后在工程鏈接文件里將這個自定義.sdramCodeSection段放到SDRAM空間里，這樣我們在外部Flash和SDRAM空間里就都有readonly段了，跟客戶情況一致了。

place in DATA3_region { section .sdramCodeSection };

板卡上電，直接用板載DAP-Link調試器在線下載工程（為了減少對板子設置的依賴，我們將調試器復位類型改為Core），下載過程中IAR果然一直在報錯，如果你忽略錯誤繼續調試，雖然斷點會停在main函數，但是只要單步進放到SDRAM空間的函數里時，程序就會跑飛進hardfault，因為SDRAM中根本就沒有正確的.sdramCodeSection段數據。

分析到這里，其實你應該知道問題出在哪里了，工程配套宏文件evkmimxrt1060_sdram_init.mac本應負責SDRAM初始化，但是其執行順序在 FlashIMXRT1060_FlexSPI.out作用之后，所以沒有產生其該有的效果，這個具體可見舊文 《IAR內部C-SPY調試組件配套宏文件(.mac)用法介紹》 3.1 小節，有非常詳細的解釋。

現在的解決思路就是，如何讓evkmimxrt1060_sdram_init.mac里的SDRAM初始化語句在flashloader作用之前生效，所以我們很自然地想在flashloader配套的宏文件FlashIMXRT1060_FlexSPI.mac里的execUserFlashInit()接口里將SDRAM初始化語句都加上，但是很遺憾，這招不奏效，其實在第一節介紹的case3里就應該認清現實了，內部RAM無需初始化IAR也無法正常下載。

其實IAR軟件設計里，對于兩個readonly段，只要其中有一個段被放入了Flash里（即需要flashloader），那么另外一個段不管是不是放在Flash里也需要有相應flashloader，這里痞子衡要吐槽下IAR的設計，有點呆板了。

所以本文案例里解決問題的關鍵就是為SDRAM也設計一個flashloader，具體制作方法可以參考舊文《串行NOR Flash下載算法(IAR EWARM篇)》。因為SDRAM擦寫其實也不需要什么特殊命令時序，就是單純AHB方式地寫就行了，所以這個SDRAM版本的flashloader就是個傀儡flashloader而已。

為了讓這個傀儡flashloader更通用一些，是按如下方式實現三個主要flashloaderAPI的，其中FlashInit()函數里故意沒有加SEMC模塊初始化代碼，就是為了讓這個flashloader適用所有類型的RAM（ITCM/DTCM/OCRAM/SDRAM/PSRAM/HyperRAM），外設初始化工作放在傀儡 flashloader配套宏文件里去完成。

FlashInit() - 什么都不做，直接返回

FlashWrite() - 用memcpy 函數實現

FlashErase() - 用memset 函數實現

最終RAM型通用flashloader源碼工程地址如下：

https://github.com/JayHeng/imxrt-tool-flash-algo/tree/master/boards/nxp_evkmimxrt1060_rev.a1/ram_algo/IAR

我們把新生成的SDRAM flashloader相關的所有文件(.out/.flash/.mac)放到對應IAR系統目錄下，并且修改原來的FlashIMXRT1060_EVK_FlexSPI.board 文件，加入SDRAM 相關的部分：

1. FlashIMXRT1060_SEMC.mac文件基本沿用evkmimxrt1060_sdram_init.mac文件，只是setup宏函數從execUserPreload換到execUserFlashInit

2. FlashIMXRT1060_SEMC.flash文件內容按FlashIMXRT1060_FlexSPI1.flash寫即可，注意文件后綴一定要是 .flash，IAR只認這個后綴。

現在再去下載調試，就一切正常了，說明雙Flashloader解決方案生效了。

本例是以IAR flashloader為例的，如果用J-Link flashloader也是可以的，一樣的原理制作兩個Flashloader即可。