痞子衡嵌入式：在IAR開發環境下將整個源檔案代碼重定向到任意RAM中的方法-有解無憂

　　大家好，我是痞子衡，是正經搞技術的痞子，今天痞子衡給大家分享的是在IAR開發環境下將整個源檔案代碼重定向到任意RAM中的方法，

　　痞子衡舊文《在IAR下將關鍵函式重定向到RAM中執行的方法》里介紹了三種關鍵函式重定向方法，不過這三種方法只是寫法形式不同，本質上沒啥區別，都是利用 IAR 聯結器特性將函式重定向到工程資料段（RW）所在 RAM 里，

　　對于 i.MXRT 這種擁有多塊地址非連續的 RAM 的芯片，其實我們也可以單獨將這些重定向函式放到一個指定的 RAM 里，不一定非得跟資料段放在同一個 RAM 里，具體實作也很簡單，只需要在鏈接檔案里額外加一句 place in 陳述句處理即可，恩智浦官方 SDK 包里就是這么做的，

　　然而痞子衡最近在支持 i.MXRT1170 客戶程序中，不使用恩智浦 SDK 里那種自定義函式段處理的方法，而是在 IAR 鏈接檔案里使用指定源檔案 object 的方式將代碼重定向到 ITCM 竟然失效了，這是怎么回事？今天我們一起來看一下：

Note 1：閱讀本文前需要對《IAR鏈接檔案(.icf)》、《IAR映射檔案(.map)》這兩種檔案有所了解，

Note 2：本文使用的 IAR EWARM 軟體版本是 v9.10.2，

一、回顧SDK里函式重定向做法

　　我們以最經典的 \SDK_2.11.0_MIMXRT1170-EVK\boards\evkmimxrt1170\demo_apps\hello_world\cm7\iar 例程來看，工程 Build 選擇 flexspi_nor_debug，即代碼段放在 Flash 里（0x30000000 - ），資料段放在 DTCM 里（0x20000000 - ），

　　我們現在新建一個名為 ram_code.c 的源檔案，在這個源檔案里定義如下兩個 delay1/2() 函式，然后將這個源檔案添加進工程使用，按照 SDK 里做法，如果我們想將這兩個函式重定向，需要加 AT_QUICKACCESS_SECTION_CODE 宏來修飾，其實就是將函式放到名為 CodeQuickAccess 的自定義段里，

#define AT_QUICKACCESS_SECTION_CODE(func) func @"CodeQuickAccess"

AT_QUICKACCESS_SECTION_CODE(void delay1(void));
void delay1(void)
{
     __NOP();
}

AT_QUICKACCESS_SECTION_CODE(void delay2(void));
void delay2(void)
{
    __NOP();
    __NOP();
}

　　然后工程鏈接檔案 MIMXRT1176xxxxx_cm7_flexspi_nor.icf 里（僅摘錄部分），CodeQuickAccess 段單獨放在 ITCM 里（0x00000000 - ），這就是官方 SDK 里的實作，

define symbol m_data_start           = 0x20000000;
define symbol m_data_end             = 0x2003FFFF;
define symbol m_itcm_start           = 0x00000000;
define symbol m_itcm_end             = 0x0003FFFF;
define region DATA_region   = mem:[from m_data_start to m_data_end-__size_cstack__];
define region ITCM_region   = mem:[from m_itcm_start to m_itcm_end];
define block RW            { first readwrite, section m_usb_dma_init_data };
define block QACCESS_CODE  { section CodeQuickAccess };
initialize by copy         { readwrite, section .textrw, section CodeQuickAccess };
place in DATA_region                 { block RW };
place in ITCM_region                 { block QACCESS_CODE };

　　編譯鏈接 hello_world_demo_cm7.ewp 工程，然后查看其映射檔案（hello_world_demo_cm7.map）找到跟 delay1/2() 函式相關的內容如下，顯然這是符合預期的，這里特別注意一下，CodeQuickAccess 的類別顯示的是 inited，表明其不是常見的 ro code，而是經過重定向的，而且 delay1/2() 函式所在 ram_code.o 里包含了 10 個位元組的 rw code，

*******************************************************************************
*** PLACEMENT SUMMARY
***
define block QACCESS_CODE { section CodeQuickAccess };
"P8":  place in [from 0x0 to 0x3'ffff] { block QACCESS_CODE };

  Section              Kind         Address      Size  Object
  -------              ----         -------      ----  ------
"P8":                                           0xc
  QACCESS_CODE                          0x0     0xc  <Block>
    QACCESS_CODE-1                      0x0     0xa  <Init block>
      CodeQuickAccess  inited           0x0     0xa  ram_code.o [6]
                                      - 0xc     0xc

*******************************************************************************
*** MODULE SUMMARY
***
    Module                              ro code  rw code  ro data  rw data
    ------                              -------  -------  -------  -------
    ram_code.o                                        10       10

*******************************************************************************
*** ENTRY LIST
***
    Entry                       Address   Size  Type      Object
    ----                       -------   ----  ----      ------
    delay1                          0x1    0x4  Code  Gb  ram_code.o [6]
    delay2                          0x5    0x6  Code  Gb  ram_code.o [6]

　　如果你打開工程鏡像檔案 hello_world_demo_cm7.srec 查看，這里也只有一段連續的 Flash 地址空間資料，沒有 RAM 地址空間資料，所以這個鏡像檔案是符合獨立工具（比如 MCUBootUtility）下載以及 BootROM 啟動條件的，

二、引出源檔案Object方式重定向失效問題

　　現在來看客戶遇到的問題，客戶不想在源檔案里逐一修飾需要重定向的函式（即 ram_code.c 檔案里 delay1/2() 函式不加 AT_QUICKACCESS_SECTION_CODE 修飾），這種情況下我們需要改動一下鏈接檔案，將 object ram_code.o 放到 initialize by copy 陳述句和 place in ITCM_region 陳述句里，

initialize by copy         { readwrite, section .textrw, section CodeQuickAccess, object ram_code.o };
place in ITCM_region       { object ram_code.o };

　　這時候重新編譯鏈接工程，查看映射檔案，找到跟 delay1/2() 函式相關的內容如下，這個結果跟第一小節里結果有點區別，雖然 delay1/2() 確實鏈接在了 ITCM 里（0x00000000 - ），但是同時也增加了 0x0 - 0xb 區域的 Initializer bytes，

*******************************************************************************
*** PLACEMENT SUMMARY
***
define block QACCESS_CODE { section CodeQuickAccess };
"P8":  place in [from 0x0 to 0x3'ffff] { block QACCESS_CODE };
"P9":  place in [from 0x0 to 0x3'ffff] { object ram_code.o };

  Section              Kind         Address    Size  Object
  -------              ----         -------    ----  ------
"P8-P9":                                       0x18
  Initializer bytes    const            0x0     0xc  <for P8-P9-1>
  P8-P9-1                               0xc     0xa  <Init block>
    .text              inited           0xc     0xa  ram_code.o [6]
                                     - 0x16    0x16

*******************************************************************************
*** MODULE SUMMARY
***
    Module                              ro code  ro data  rw data
    ------                              -------  -------  -------
    ram_code.o                                        10       10

*******************************************************************************
*** ENTRY LIST
***
    Entry                       Address   Size  Type      Object
    ----                       -------   ----  ----      ------
    delay1                          0xd    0x4  Code  Gb  ram_code.o [6]
    delay2                         0x11    0x6  Code  Gb  ram_code.o [6]

　　如果此時再打開工程鏡像檔案 hello_world_demo_cm7.srec 查看，除了 Flash 地址空間資料，還新增了 RAM 地址空間資料，很顯然這個鏡像檔案不符合獨立工具（比如 MCUBootUtility）下載以及 BootROM 啟動，僅能用于 IDE 中在線下載除錯（即分散加載了），

三、源檔案Object方式重定向失效分析

　　我們再做一個實驗，按《在IAR下將關鍵函式重定向到RAM中執行的方法》一文 2.3 針對源檔案中全部函式 方法，在鏈接檔案中僅將 object ram_code.o 放到 initialize by copy 陳述句里，那么 ram_code.o 中的內容會被統一重定向到工程資料段 RW 所在 RAM 區域里（即 DTCM 0x20000000 -），這種情況下 delay1/2() 函式重定向是成功的，

initialize by copy         { readwrite, section .textrw, section CodeQuickAccess, object ram_code.o };
//place in ITCM_region       { object ram_code.o };

　　所以我們能夠得出結論，在不自定義函式段名的情況下，object ram_code.o 中內容會在默認 RO、RW 段里，在做函式重定向時，IAR 聯結器無法將對應 ram_code.o 的 Initializer bytes 從默認 RO 段里單獨提取出來拷貝到非 RW 段所在區，它只能統一處理 RO 段 Initializer bytes 到 RW 區的拷貝，如果硬要將 object ram_code.o 重定向到非 RW 所在 RAM 區，IAR 聯結器會直接將其 Initializer bytes 也從 RO 段里抽出來，與其 RW 屬性的 .text 放在一起，這其實幾乎等效于分散加載了，

四、源檔案Object方式重定向失效解決方案

　　分析到這里，解決方案清晰了，還是需要自定義程式段，不過既然不想單個函式加修飾，那有沒有整個檔案范圍內代碼統一加修飾呢？當然是有的，這時候需要借助如下 #pragma default_function_attributes 語法，將這一對陳述句放置到源檔案首行和末行，那么該源檔案里所有函式都進入了 .myCodeSection 自定義段里：

// 作用全部函式
#pragma default_function_attributes = @ ".myCodeSection"
// 作用全部變數（如有必要）
//#pragma default_variable_attributes = @ ".myVariSection"

void delay1(void)
{
     __NOP();
}

void delay2(void)
{
    __NOP();
    __NOP();
}

#pragma default_function_attributes =
//#pragma default_variable_attributes =

　　然后在工程鏈接檔案 MIMXRT1176xxxxx_cm7_flexspi_nor_sdram.icf 里直接將 section .myCodeSection 放到 ITCM 里就可以了：

initialize by copy         { readwrite, section .textrw, section CodeQuickAccess, section .myCodeSection };
place in ITCM_region       { section .myCodeSection };

　　這時候再編譯鏈接工程查看映射檔案，函式重定向結果就符合預期了，這個結果跟第一小節里的結果一致，

*******************************************************************************
*** PLACEMENT SUMMARY
***
"P8":  place in [from 0x0 to 0x3'ffff] { block QACCESS_CODE };
"P9":  place in [from 0x0 to 0x3'ffff] { section .myCodeSection };

  Section              Kind         Address    Size  Object
  -------              ----         -------    ----  ------
"P8-P9":                                        0xc
  P8-P9                                 0x0     0xc  <Init block>
    .myCodeSection     inited           0x0     0xa  ram_code.o [6]
                                      - 0xc     0xc

*******************************************************************************
*** MODULE SUMMARY
***
    Module                              ro code  rw code  ro data  rw data
    ------                              -------  -------  -------  -------
    ram_code.o                                        10       10

*******************************************************************************
*** ENTRY LIST
***
    Entry                       Address   Size  Type      Object
    ----                       -------   ----  ----      ------
    delay1                          0x1    0x4  Code  Gb  ram_code.o [6]
    delay2                          0x5    0x6  Code  Gb  ram_code.o [6]

　　至此，在IAR開發環境下將整個源檔案代碼重定向到任意RAM中的方法痞子衡便介紹完畢了，掌聲在哪里~~~

歡迎訂閱

文章會同時發布到我的博客園主頁、CSDN主頁、知乎主頁、微信公眾號平臺上，

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

最后歡迎關注痞子衡個人微信公眾號【痞子衡嵌入式】，一個專注嵌入式技術的公眾號，跟著痞子衡一起玩轉嵌入式，

衡杰(痞子衡)，目前就職于恩智浦MCU系統部門，擔任嵌入式系統應用工程師，

專欄內所有文章的轉載請注明出處：http://www.cnblogs.com/henjay724/

與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]

可以關注痞子衡的Github主頁 https://github.com/JayHeng，有很多好玩的嵌入式專案，

關于專欄文章有任何疑問請直接在博客下面留言，痞子衡會及時回復免費(劃重點)答疑，

痞子衡郵箱已被私信擠爆，技術問題不推薦私信，堅持私信請先掃碼付款(5元起步)再發，

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/412804.html

標籤：其他

上一篇：記錄一次shell腳本環境全域變數在函式內部生效問題

下一篇：001 研發同學必學哪些 Linux 命令？