1. 先看懂L6236E在說什么鏈接器找不到第一個出場的代碼段用Keil MDK開發(fā)的朋友十有八九都撞到過這個報錯。當時我第一回見是在一個接手項目的第二天——別人給的工程一編譯直接卡死在鏈接階段彈出一行紅色的.\Objects\xxx.sct(7): error: L6236E: No section matches selector - no section to be FIRST/LAST.行號還不固定有時候是第7行有時候是第3行但錯誤碼永遠是這個L6236E。很多人第一反應是去網(wǎng)上搜怎么解決但說實話你如果不懂這行字背后的鏈接機制搜來的答案大概率是加個啟動文件檢查一下芯片型號這種知其然不知其所以然的回復照著弄可能碰巧好了換個場景又廢。先把這行報錯拆開看。在ARM Compiler的鏈接階段鏈接器會讀取分散加載描述文件就是.sct文件這個文件里定義了ROM、RAM的分布區(qū)域以及每個區(qū)域里應該放什么內(nèi)容。以最常見的STM32工程為例默認生成的xxx.sct大概長這樣; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x08000000 0x00080000 { ; load region size_region ER_IROM1 0x08000000 0x00080000 { ; load address execution address *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) .ANY (XO) } RW_IRAM1 0x20000000 0x00010000 { ; RW data .ANY (RW ZI) } }重點看這行*.o (RESET, First)意思是在某個目標文件*.o里必須存在一個名為RESET的代碼/數(shù)據(jù)段并且它要被放在這個region的最前面First。這個RESET段就是啟動文件里的中斷向量表。處理器復位后第一條指令從0x08000000取到的是棧頂?shù)刂肪o接著取到的是復位向量地址這決定了程序必須在這個位置放中斷向量表?，F(xiàn)在你回頭看那個報錯No section matches selector - no section to be FIRST/LAST.它的意思就是鏈接器在整個工程的編譯產(chǎn)物里沒找到任何一個滿足條件、能被標記為FIRST或LAST的section。翻譯成大白話——你工程里壓根沒有一個叫RESET的段或者說沒有任何一段代碼被指定放到這個位置所以鏈接器直接罷工了。那問題就變成為什么好好的工程會沒有RESET段下面幾節(jié)我把實戰(zhàn)里遇到過的原因一個一個捋并且給出驗證方法避免你瞎猜。2. 從啟動文件入手排查九成的L6236E都在這兒2.1 啟動文件到底去哪兒了這是最常見的情況沒有之一。Keil工程樹里的源文件其實分幾種狀態(tài)普通參與編譯、被排除構建Exclude from build、以及壓根不在工程里。很多人接手舊工程或者自己在網(wǎng)上下了個Demo會發(fā)現(xiàn)工程樹里所有文件都在唯獨少了startup開頭的那個文件。STM32的啟動文件命名通常是這樣的startup_stm32f103xe.sstartup_stm32f407xx.sstartup_stm32f429xx.s或者老一些的startup_stm32f10x_hd.s這個文件就是產(chǎn)生RESET段的源頭它里面寫了整個中斷向量表包括初始棧指針、復位處理器、各個中斷的默認處理函數(shù)。沒有它編譯器再努力也編不出RESET段。排查方法很簡單在Keil左側Project窗口展開你的目標分組找有沒有.s后綴的文件找到了就先雙擊打開看一眼里面有沒有AREA RESET, CODE, READONLY這行不同芯片寫法略有差異但關鍵詞是RESET確認文件在但編譯還是報L6236E——右鍵該文件看選項里Options for File中Exclude from build是否被勾上了。勾了就取消重新編譯。這里插一句很多人在網(wǎng)上下的HAL庫Demo或者GitHub上拉的開源工程作者用的是IAR或者STM32CubeIDE文件夾里根本沒放Keil的啟動文件。這時候你不能只加個空文件必須去ST官方固件庫的CMSIS/Device/ST/STM32F1xx/Source/Templates/arm目錄下找對應型號的啟動文件加進工程。2.2 芯片型號和啟動文件不匹配這種錯誤更隱蔽編譯不報錯但鏈接必炸。我舉個例子。假設你現(xiàn)在用的是STM32F103ZET6512KB Flash但工程里掛的啟動文件是startup_stm32f103c8t6.s64KB Flash的多見于小容量芯片。啟動文件里不只會放向量表還會定義堆棧大小、以及一些芯片特有的初始化方式。兩者混用在某些鏈接配置下不會直接報型號不對而是導致section屬性異常最后就推送出L6236E。更典型的場景是從F1往F4遷移或者在F407和F429之間切換。有人為了省事?lián)Q芯片后只改了Device型號啟動文件還是老的。F4系列的啟動文件在向量表長度、SystemInit調(diào)用方式上和F1完全不同這時候報的錯五花八門L6236E就是其中之一。驗證與處理點擊魔術棒Options for Target→ Device選項卡確認當前選擇的芯片型號去ST固件庫里找到對應型號的Keil啟動文件替換工程里原有的替換完務必把原來那個.s文件從工程里移除別讓兩個啟動文件同時存在。工程里掛兩個啟動文件是個非常經(jīng)典的低級錯誤鏈接器有可能會去匹配其中任意一個的RESET段結果兩個都不是合法定義照樣報錯。2.3 C/C選項卡里的宏定義被清空這點很多老手都會忽略但新手特別容易踩。某些芯片的啟動文件里不僅僅有向量表還包含一些條件編譯的代碼。比如有些F1系列的啟動文件里會通過STM32F10X_HD這種宏來決定是否編譯進大容量芯片特有的中斷處理。Cortex-M內(nèi)核的芯片啟動文件相對干凈但很多廠商比如GD32、華大、NXP的部分系列的啟動文件里都會預編譯宏相關的判斷。當你在C/C選項卡的Define框里把宏刪了或者覆蓋了啟動文件里的一部分段定義就不會被編譯進去RESET段缺失鏈接階段就冒出L6236E。檢查方法打開 Options for Target → C/C → Preprocessor Symbols → Define對照芯片型號查看是否缺少必須的宏。以STM32F103系列為例如果用標準外設庫至少要有STM32F10X_HD或STM32F10X_MD這類區(qū)分容量的宏具體看是Standard Peripheral Library還是HAL庫HAL庫通常需要STM32F103xE這種宏可以用一個已知能正常編譯的工程作為參照把Define里的內(nèi)容補全。提示有些移植老工程的朋友不知道Keil 5從某個版本起對啟動文件的默認編譯行為做了調(diào)整個別舊工程需要手動勾選Use default compiler version 5或者加--c99才能正常編過。但L6236E和編譯器版本的關系沒那么大如果上述方法都不生效再考慮這個方向。3. 分散加載文件.sct被改壞或選錯鏈接器動手腳的元兇第二種高頻場景是.sct文件本身出了問題。很多人對它理解不深覺得就是個自動生成的東西碰都不碰。但一旦你手動改過一次后面就可能埋雷。3.1 被選中執(zhí)行的.sct和實際內(nèi)容對不上Keil里分散加載文件的位置在Options for Target → Linker → Use Memory Layout from Target Dialog當你勾選Use Memory Layout from Target Dialog時Keil會根據(jù)你在Target選項卡里填的ROM/RAM地址自動生成.sct文件你不需要關心它長什么樣。但如果你取消了這個勾選下面那個Scatter File編輯框變?yōu)榭删庉嫚顟B(tài)你就可以指定一個自定義的.sct文件。問題就出在這兒——當你指定的.sct文件內(nèi)容是針對其他芯片寫的或者是從舊工程拷過來忘了改地址鏈接器就會拿著這個錯誤地圖去尋找段。舉個真實場景一個F103ZE的工程Flash是512K0x08000000–0x0807FFFF但.sct文件還是從F103C8T6工程拷來的只定義了64K0x08000000–0x0800FFFF。程序稍微大一點鏈接器在ROM區(qū)后半部分找不到足夠的空間放啟動文件定義的段就會報一堆亂七八糟的錯誤其中一定包含L6236E。另外還有一種情況是這個.sct文件雖然格式正確、地址也對但缺少了啟動段標記。比如說有人手動改過把*.o (RESET, First)這行誤刪了。那就會立刻觸發(fā)L6236E——因為鏈接器要求region有一個FIRST段但你的描述文件里根本沒說用哪段來當FIRST。排查方法打開 Options for Target → Linker檢查是否勾選了Use Memory Layout from Target Dialog如果沒勾看Scatter File指向的文件路徑用編輯器打開對照你當前芯片的起始地址和大小確認每一段region里是否包含類似的FIRST/LAST標記行尤其是第一個加載域。3.2 恢復默認.sct的操作如果排查一番發(fā)現(xiàn).sct文件里內(nèi)容亂七八糟最簡單止損的辦法是打開 Options for Target → Linker勾選Use Memory Layout from Target Dialog刪除下面Scatter File編輯框里的自定義路徑點OK重新編譯。這樣Keil會重新按照Target對話框里的IROM1/IRAM1配置自動生成一份干凈的sct文件。絕大多數(shù)情況下這個動作就能解決由于sct文件損壞導致的問題。3.3 手動改.sct時的保命原則如果你確實有需求要手動定制內(nèi)存布局比如在RAM里跑代碼、或者把某個固定地址放Bootloader的跳轉(zhuǎn)信息那么修改.sct文件時務必保留每個region內(nèi)部的FIRST/LAST聲明。一個可用的最小示例LR_IROM1 0x08000000 0x00100000 { ER_IROM1 0x08000000 0x00100000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) .ANY (XO) } RW_IRAM1 0x20000000 0x00020000 { .ANY (RW ZI) } }如果你自定義了某個段放在固定地址比如要用__attribute__((section(MY_DATA)))可以在RW區(qū)加一行RW_IRAM1 0x20000000 0x00020000 { .ANY (RW ZI) *(.MY_DATA) }反過來如果你的項目里確實沒有啟動文件比如純內(nèi)存初始化、或者某個已經(jīng)初始化好環(huán)境的場景你需要把*.o (RESET, First)刪掉同時把ER_IROM1里的First屬性改成其他段名。但這是極少數(shù)場景普通應用不要碰。4. 進階排查鏈路從.map文件和鏈接日志找到真正的斷點如果前面幾招都試過了還不行就說明問題不像少了啟動文件這么簡單。這時候我建議你不要繼續(xù)盲試而是翻開鏈接器給出的詳細日志和生成產(chǎn)物進行邏輯推理。4.1 打開鏈接器的詳細輸出默認情況下Keil的Build Output只顯示錯誤和警告很多細節(jié)被吞了。你可以通過設置讓鏈接器輸出更詳細的信息Options for Target → Listing → 在Linker Listing區(qū)域勾選所有項目尤其是Memory Map 和 Cross Reference重新編譯后在工程目錄的Listings文件夾下會生成一個.map文件用記事本打開。先看文件末尾的Image Symbol Table和Memory Map of the image確認啟動文件里的標號是否存在。正常情況下你會看到類似Reset_Handler 0x08000000 Code SystemInit 0x080001b8 Code __Vectors 0x08000000 Data ; 注意某些編譯器把向量表識別為Data如果連__Vectors、Reset_Handler都沒有基本可以確認RESET段沒有被打進最終鏡像。4.2 用ARM編譯器工具鏈做尸檢Keil安裝目錄下有一堆命令行工具其中fromelf很實用可以把最終ELF文件反匯編/導出詳細信息。命令類似于fromelf --text -z -d --outputoutput.txt .\Objects\YourProject.axf-z是顯示零初始化段信息-d是反匯編代碼段。查看生成的txt里有沒有Reset_Handler和__Vectors再看它們的地址是不是落在0x08000000附近。如果沒有生成.axf文件說明鏈接失敗看不到產(chǎn)物。這時候可以考慮先注釋掉.sct里的FIRST行臨時編一個不要求FIRST的鏡像看看能不能鏈接成功。如果這樣能出.axf就證明問題確實出在沒有可用的RESET段而不是.sct文件其他地方的語法或地址問題。4.3 查看Build Output窗口最頂部的警告有些L6236E報錯之前其實編譯過程已經(jīng)給出過警告只不過在長長的輸出里被滾動淹沒了。編譯完后從Build Output窗口的最頂上開始往下翻留意類似這樣的信息compiling startup_stm32f103xe.s... assembling startup_stm32f103xe.s...如果有assembling這行說明啟動文件被匯編器正常處理了。如果這一行都沒出現(xiàn)說明這個.s文件根本沒進入編譯流程——這時候就算你加再多的.sct配置也白搭。我遇到過一種情況工程里.s文件確實在但我用的Arm Compiler 6編譯器需要額外的匯編選項結果啟動文件被靜默跳過。后來在.s文件的Options里把Assembler選項卡的Assemble Thumb Code和相關配置改成和默認工程一致問題才解決。4.4 從報錯行號反推哪個region缺段L6236E報錯信息里括號中的數(shù)字比如.sct(7)指的就是出錯位置在第7行。你可以打開自己工程的鏈接文件數(shù)一數(shù)是哪一行對應的region報錯。以我前面的示例sct為例第1行: ; ************************************************************* 第2行: ; *** Scatter-Loading Description File generated by uVision *** 第3行: ; ************************************************************* 第4行: 第5行: LR_IROM1 0x08000000 0x00080000 { 第6行: ER_IROM1 0x08000000 0x00080000 { 第7行: *.o (RESET, First) 第8行: *(InRoot$$Sections) 第9行: .ANY (RO) 第10行: .ANY (XO) 第11行: } 第12行: RW_IRAM1 0x20000000 0x00010000 { ...報錯說是第7行對應就是*.o (RESET, First)這一句。所以該行所要求的RESET段缺失。如果你的報錯行號是其他行比如指向LR_IROM1那一行說明整個加載域都有問題可能就是地址重疊或者非法。這個方法能幫你快速確認到底是所有region都沒段匹配還是只有某一個region缺段。這兩種情況的處理邏輯不太一樣——前者通常是啟動文件缺失后者往往是段選擇器的寫法問題。5. 從CubeMX生成工程和舊工程遷移中的特殊雷區(qū)5.1 STM32CubeMX生成的Keil工程為什么也會報L6236E這幾年用CubeMX建工程的人越來越多按理說它生成的工程應該是開箱即用的。但你要是遇到過以下操作照樣會踩到L6236E生成工程后手動把startup_stm32xxxx.s文件從工程里刪了想自己寫啟動邏輯用CubeMX切換了芯片型號但Project Manager → Project里的工具鏈設置沒跟著變或者舊啟動文件沒被覆蓋在.ioc文件里改了Flash/RAM大小但重新生成代碼時勾選了備份舊工程結果新舊啟動文件混雜使用了自己添加的鏈接腳本而CubeMX自動生成的sct被覆蓋了。第一種場景比較難辦。如果你確定不要ST的啟動文件那么你得自己提供一個向量表段并且保證它帶有初始棧指針和復位向量。很多從裸機匯編開始寫固件的老工程師會這么干但對于絕大多數(shù)應用來說直接用官方啟動文件是成本最低、最穩(wěn)妥的方案。第二種場景的處理方法是在CubeMX里重新選擇正確的芯片然后在Project Manager → Linker Settings里確認Heap/Stack大小沒問題最后重新生成代碼讓CubeMX把啟動文件一并刷新。5.2 舊工程換芯片最完整的操作順序如果你手上有個F103C8T6的舊工程要改成F103ZET6千萬別只改Device型號就完事。我的標準操作順序如下你可以直接照著做備份整個工程目錄這一步每次都要做別省Options for Target → Device選擇新芯片Options for Target → Target核對ROM/RAM地址和大小。F103C8T6的RAM是20KB0x20000000大小0x5000Flash 64KB0x08000000大小0x10000換成F103ZET6后RAM是64KB0x10000Flash是512KB0x80000從ST官方固件庫或者另一個正常運行的F103ZET6工程里復制startup_stm32f103xe.s到工程目錄然后在Keil里刪除舊啟動文件、添加新啟動文件檢查C/C選項卡的DefineF103ZE對應STM32F10X_HD標準外設庫或STM32F103xEHAL庫清理編譯產(chǎn)物點Rebuild不是Build是Rebuild。如果還報錯去檢查Linker選項卡里是否勾著Use Memory Layout from Target Dialog確認Scatter File路徑?jīng)]有指向舊芯片的sct。這套流程走下來L6236E基本不會再出現(xiàn)。5.3 使用AC5和AC6編譯器時的啟動文件差異Keil MDK從5.x版本開始默認的編譯器逐漸向Arm Compiler 6基于Clang遷移。AC6和AC5在處理匯編啟動文件上有很多差異這一點會被很多人忽略。AC5使用的armcc/armasm對.s匯編文件的語法比較寬松。而AC6使用的armclang內(nèi)置的匯編器對偽指令的支持不夠全面某些老啟動文件在AC6下會匯編失敗或者產(chǎn)生不同的段屬性。如果你的工程是從AC5遷移到AC6后開始報L6236E優(yōu)先檢查啟動文件是否是比較老、為AC5編寫的版本ST官方針對AC6發(fā)布過新版本的啟動文件CMSIS pack里的通常沒問題在Options for Target → Target → ARM Compiler里嘗試暫時切換回Use default compiler version 5如果能編譯通過說明就是啟動文件對AC6兼容性的問題。從Arm Compiler 5切到6之后很多舊版啟動文件會直接報匯編錯誤不會走到L6236E這一步。但有一種情況是匯編只產(chǎn)生警告沒有報錯最后段的屬性不對才最終在鏈接階段爆炸。5.4 工程路徑和特殊字符的隱患這個方法很少有人提最后分享一個很多人不會第一時間想到的原因工程所在路徑太長或者包含中文、空格、特殊符號。當年我遇到過一個很邪門的L6236E所有的檢查和替換都做完了問題就是復現(xiàn)不了。折騰了一下午最后把整個工程文件夾從D:\工作文件\測試項目\基于STM32的溫控系統(tǒng)_V2_最終版(1)\挪到D:\keil_projects\temp\重新編譯一切正常。原因大概是鏈接器在解析sct里通配符和路徑時對中文字符和多級嵌套目錄的處理在某些編譯器版本里有Bug。雖然這個bug不是每次必現(xiàn)但一旦遇到排查起來極其耗費時間。所以建議你的工程存放路徑盡量滿足全英文不要有空格層級不要超過三四級不要以數(shù)字開頭在某些老版本里也會出問題更不要放在桌面這種權限有時受限的目錄下。6. 實操總結最快的解決路徑和一套順手能用的驗證方法我把上面所有的排查邏輯壓縮成一套可以直接照做的動作建議你按順序執(zhí)行不要跳步。第一步確認啟動文件存在且參與編譯工程樹里有沒有.s文件右鍵.s文件 → Options for File → 確認 Exclude from Build 未勾選。打開.s文件搜索AREA和RESET關鍵字。第二步檢查芯片型號和宏定義Options for Target → Device確認芯片型號。Options for Target → C/C確認Define里有對應型號的宏。如果不確定宏應該是什么去正常能編譯的工程抄一份或者查ST官方模板。第三步重置分散加載文件Options for Target → Linker勾選Use Memory Layout from Target Dialog清除自定義Scatter File路徑。Options for Target → Target確認IROM1起始地址0x08000000大小按芯片F(xiàn)lash實際大小填IRAM1起始0x20000000大小按芯片實際RAM填。Rebuild整個工程。第四步查看詳細鏈接輸出定位Options for Target → Listing勾選Linker Listing下的Memory Map、Cross Reference等。重新編譯后打開.map文件搜索Reset_Handler和__Vectors。如果找不到說明啟動段的產(chǎn)生就有問題回頭檢查匯編文件。也可以用fromelf反匯編.axf文件驗證段地址。第五步整路徑、整編譯器工程路徑改成純英文短路徑。嘗試在Target選項卡里切AC5/AC6判斷是否是編譯器兼容性問題。這套流程我前前后后幫同事處理了不下十次耗時從幾分鐘到一下午都有。但其實九成以上的情況走完第二步就能解決第三步都很少需要用到。再分享一個我自己的習慣**每次新建工程時先不寫任何業(yè)務代碼只放一個main函數(shù)和一個printf重定向確認能在這個工程模板里編譯、下載、跑通串口再往里加功能。**這樣一旦后面報錯你能確定是新增代碼導致的問題而不是工程基礎配置本來就有毛病。L6236E這類鏈接錯誤說白了就是工程配置和實際代碼對不上號你得讓工程底子干凈問題才好定位。 STM32鏈接報錯L6236E？啟動文件與分散加載文件排查指南
1. 先看懂L6236E在說什么鏈接器找不到第一個出場的代碼段用Keil MDK開發(fā)的朋友十有八九都撞到過這個報錯。當時我第一回見是在一個接手項目的第二天——別人給的工程一編譯直接卡死在鏈接階段彈出一行紅色的.\Objects\xxx.sct(7): error: L6236E: No section matches selector - no section to be FIRST/LAST.行號還不固定有時候是第7行有時候是第3行但錯誤碼永遠是這個L6236E。很多人第一反應是去網(wǎng)上搜怎么解決但說實話你如果不懂這行字背后的鏈接機制搜來的答案大概率是加個啟動文件檢查一下芯片型號這種知其然不知其所以然的回復照著弄可能碰巧好了換個場景又廢。先把這行報錯拆開看。在ARM Compiler的鏈接階段鏈接器會讀取分散加載描述文件就是.sct文件這個文件里定義了ROM、RAM的分布區(qū)域以及每個區(qū)域里應該放什么內(nèi)容。以最常見的STM32工程為例默認生成的xxx.sct大概長這樣; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x08000000 0x00080000 { ; load region size_region ER_IROM1 0x08000000 0x00080000 { ; load address execution address *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) .ANY (XO) } RW_IRAM1 0x20000000 0x00010000 { ; RW data .ANY (RW ZI) } }重點看這行*.o (RESET, First)意思是在某個目標文件*.o里必須存在一個名為RESET的代碼/數(shù)據(jù)段并且它要被放在這個region的最前面First。這個RESET段就是啟動文件里的中斷向量表。處理器復位后第一條指令從0x08000000取到的是棧頂?shù)刂肪o接著取到的是復位向量地址這決定了程序必須在這個位置放中斷向量表?，F(xiàn)在你回頭看那個報錯No section matches selector - no section to be FIRST/LAST.它的意思就是鏈接器在整個工程的編譯產(chǎn)物里沒找到任何一個滿足條件、能被標記為FIRST或LAST的section。翻譯成大白話——你工程里壓根沒有一個叫RESET的段或者說沒有任何一段代碼被指定放到這個位置所以鏈接器直接罷工了。那問題就變成為什么好好的工程會沒有RESET段下面幾節(jié)我把實戰(zhàn)里遇到過的原因一個一個捋并且給出驗證方法避免你瞎猜。2. 從啟動文件入手排查九成的L6236E都在這兒2.1 啟動文件到底去哪兒了這是最常見的情況沒有之一。Keil工程樹里的源文件其實分幾種狀態(tài)普通參與編譯、被排除構建Exclude from build、以及壓根不在工程里。很多人接手舊工程或者自己在網(wǎng)上下了個Demo會發(fā)現(xiàn)工程樹里所有文件都在唯獨少了startup開頭的那個文件。STM32的啟動文件命名通常是這樣的startup_stm32f103xe.sstartup_stm32f407xx.sstartup_stm32f429xx.s或者老一些的startup_stm32f10x_hd.s這個文件就是產(chǎn)生RESET段的源頭它里面寫了整個中斷向量表包括初始棧指針、復位處理器、各個中斷的默認處理函數(shù)。沒有它編譯器再努力也編不出RESET段。排查方法很簡單在Keil左側Project窗口展開你的目標分組找有沒有.s后綴的文件找到了就先雙擊打開看一眼里面有沒有AREA RESET, CODE, READONLY這行不同芯片寫法略有差異但關鍵詞是RESET確認文件在但編譯還是報L6236E——右鍵該文件看選項里Options for File中Exclude from build是否被勾上了。勾了就取消重新編譯。這里插一句很多人在網(wǎng)上下的HAL庫Demo或者GitHub上拉的開源工程作者用的是IAR或者STM32CubeIDE文件夾里根本沒放Keil的啟動文件。這時候你不能只加個空文件必須去ST官方固件庫的CMSIS/Device/ST/STM32F1xx/Source/Templates/arm目錄下找對應型號的啟動文件加進工程。2.2 芯片型號和啟動文件不匹配這種錯誤更隱蔽編譯不報錯但鏈接必炸。我舉個例子。假設你現(xiàn)在用的是STM32F103ZET6512KB Flash但工程里掛的啟動文件是startup_stm32f103c8t6.s64KB Flash的多見于小容量芯片。啟動文件里不只會放向量表還會定義堆棧大小、以及一些芯片特有的初始化方式。兩者混用在某些鏈接配置下不會直接報型號不對而是導致section屬性異常最后就推送出L6236E。更典型的場景是從F1往F4遷移或者在F407和F429之間切換。有人為了省事?lián)Q芯片后只改了Device型號啟動文件還是老的。F4系列的啟動文件在向量表長度、SystemInit調(diào)用方式上和F1完全不同這時候報的錯五花八門L6236E就是其中之一。驗證與處理點擊魔術棒Options for Target→ Device選項卡確認當前選擇的芯片型號去ST固件庫里找到對應型號的Keil啟動文件替換工程里原有的替換完務必把原來那個.s文件從工程里移除別讓兩個啟動文件同時存在。工程里掛兩個啟動文件是個非常經(jīng)典的低級錯誤鏈接器有可能會去匹配其中任意一個的RESET段結果兩個都不是合法定義照樣報錯。2.3 C/C選項卡里的宏定義被清空這點很多老手都會忽略但新手特別容易踩。某些芯片的啟動文件里不僅僅有向量表還包含一些條件編譯的代碼。比如有些F1系列的啟動文件里會通過STM32F10X_HD這種宏來決定是否編譯進大容量芯片特有的中斷處理。Cortex-M內(nèi)核的芯片啟動文件相對干凈但很多廠商比如GD32、華大、NXP的部分系列的啟動文件里都會預編譯宏相關的判斷。當你在C/C選項卡的Define框里把宏刪了或者覆蓋了啟動文件里的一部分段定義就不會被編譯進去RESET段缺失鏈接階段就冒出L6236E。檢查方法打開 Options for Target → C/C → Preprocessor Symbols → Define對照芯片型號查看是否缺少必須的宏。以STM32F103系列為例如果用標準外設庫至少要有STM32F10X_HD或STM32F10X_MD這類區(qū)分容量的宏具體看是Standard Peripheral Library還是HAL庫HAL庫通常需要STM32F103xE這種宏可以用一個已知能正常編譯的工程作為參照把Define里的內(nèi)容補全。提示有些移植老工程的朋友不知道Keil 5從某個版本起對啟動文件的默認編譯行為做了調(diào)整個別舊工程需要手動勾選Use default compiler version 5或者加--c99才能正常編過。但L6236E和編譯器版本的關系沒那么大如果上述方法都不生效再考慮這個方向。3. 分散加載文件.sct被改壞或選錯鏈接器動手腳的元兇第二種高頻場景是.sct文件本身出了問題。很多人對它理解不深覺得就是個自動生成的東西碰都不碰。但一旦你手動改過一次后面就可能埋雷。3.1 被選中執(zhí)行的.sct和實際內(nèi)容對不上Keil里分散加載文件的位置在Options for Target → Linker → Use Memory Layout from Target Dialog當你勾選Use Memory Layout from Target Dialog時Keil會根據(jù)你在Target選項卡里填的ROM/RAM地址自動生成.sct文件你不需要關心它長什么樣。但如果你取消了這個勾選下面那個Scatter File編輯框變?yōu)榭删庉嫚顟B(tài)你就可以指定一個自定義的.sct文件。問題就出在這兒——當你指定的.sct文件內(nèi)容是針對其他芯片寫的或者是從舊工程拷過來忘了改地址鏈接器就會拿著這個錯誤地圖去尋找段。舉個真實場景一個F103ZE的工程Flash是512K0x08000000–0x0807FFFF但.sct文件還是從F103C8T6工程拷來的只定義了64K0x08000000–0x0800FFFF。程序稍微大一點鏈接器在ROM區(qū)后半部分找不到足夠的空間放啟動文件定義的段就會報一堆亂七八糟的錯誤其中一定包含L6236E。另外還有一種情況是這個.sct文件雖然格式正確、地址也對但缺少了啟動段標記。比如說有人手動改過把*.o (RESET, First)這行誤刪了。那就會立刻觸發(fā)L6236E——因為鏈接器要求region有一個FIRST段但你的描述文件里根本沒說用哪段來當FIRST。排查方法打開 Options for Target → Linker檢查是否勾選了Use Memory Layout from Target Dialog如果沒勾看Scatter File指向的文件路徑用編輯器打開對照你當前芯片的起始地址和大小確認每一段region里是否包含類似的FIRST/LAST標記行尤其是第一個加載域。3.2 恢復默認.sct的操作如果排查一番發(fā)現(xiàn).sct文件里內(nèi)容亂七八糟最簡單止損的辦法是打開 Options for Target → Linker勾選Use Memory Layout from Target Dialog刪除下面Scatter File編輯框里的自定義路徑點OK重新編譯。這樣Keil會重新按照Target對話框里的IROM1/IRAM1配置自動生成一份干凈的sct文件。絕大多數(shù)情況下這個動作就能解決由于sct文件損壞導致的問題。3.3 手動改.sct時的保命原則如果你確實有需求要手動定制內(nèi)存布局比如在RAM里跑代碼、或者把某個固定地址放Bootloader的跳轉(zhuǎn)信息那么修改.sct文件時務必保留每個region內(nèi)部的FIRST/LAST聲明。一個可用的最小示例LR_IROM1 0x08000000 0x00100000 { ER_IROM1 0x08000000 0x00100000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) .ANY (XO) } RW_IRAM1 0x20000000 0x00020000 { .ANY (RW ZI) } }如果你自定義了某個段放在固定地址比如要用__attribute__((section(MY_DATA)))可以在RW區(qū)加一行RW_IRAM1 0x20000000 0x00020000 { .ANY (RW ZI) *(.MY_DATA) }反過來如果你的項目里確實沒有啟動文件比如純內(nèi)存初始化、或者某個已經(jīng)初始化好環(huán)境的場景你需要把*.o (RESET, First)刪掉同時把ER_IROM1里的First屬性改成其他段名。但這是極少數(shù)場景普通應用不要碰。4. 進階排查鏈路從.map文件和鏈接日志找到真正的斷點如果前面幾招都試過了還不行就說明問題不像少了啟動文件這么簡單。這時候我建議你不要繼續(xù)盲試而是翻開鏈接器給出的詳細日志和生成產(chǎn)物進行邏輯推理。4.1 打開鏈接器的詳細輸出默認情況下Keil的Build Output只顯示錯誤和警告很多細節(jié)被吞了。你可以通過設置讓鏈接器輸出更詳細的信息Options for Target → Listing → 在Linker Listing區(qū)域勾選所有項目尤其是Memory Map 和 Cross Reference重新編譯后在工程目錄的Listings文件夾下會生成一個.map文件用記事本打開。先看文件末尾的Image Symbol Table和Memory Map of the image確認啟動文件里的標號是否存在。正常情況下你會看到類似Reset_Handler 0x08000000 Code SystemInit 0x080001b8 Code __Vectors 0x08000000 Data ; 注意某些編譯器把向量表識別為Data如果連__Vectors、Reset_Handler都沒有基本可以確認RESET段沒有被打進最終鏡像。4.2 用ARM編譯器工具鏈做尸檢Keil安裝目錄下有一堆命令行工具其中fromelf很實用可以把最終ELF文件反匯編/導出詳細信息。命令類似于fromelf --text -z -d --outputoutput.txt .\Objects\YourProject.axf-z是顯示零初始化段信息-d是反匯編代碼段。查看生成的txt里有沒有Reset_Handler和__Vectors再看它們的地址是不是落在0x08000000附近。如果沒有生成.axf文件說明鏈接失敗看不到產(chǎn)物。這時候可以考慮先注釋掉.sct里的FIRST行臨時編一個不要求FIRST的鏡像看看能不能鏈接成功。如果這樣能出.axf就證明問題確實出在沒有可用的RESET段而不是.sct文件其他地方的語法或地址問題。4.3 查看Build Output窗口最頂部的警告有些L6236E報錯之前其實編譯過程已經(jīng)給出過警告只不過在長長的輸出里被滾動淹沒了。編譯完后從Build Output窗口的最頂上開始往下翻留意類似這樣的信息compiling startup_stm32f103xe.s... assembling startup_stm32f103xe.s...如果有assembling這行說明啟動文件被匯編器正常處理了。如果這一行都沒出現(xiàn)說明這個.s文件根本沒進入編譯流程——這時候就算你加再多的.sct配置也白搭。我遇到過一種情況工程里.s文件確實在但我用的Arm Compiler 6編譯器需要額外的匯編選項結果啟動文件被靜默跳過。后來在.s文件的Options里把Assembler選項卡的Assemble Thumb Code和相關配置改成和默認工程一致問題才解決。4.4 從報錯行號反推哪個region缺段L6236E報錯信息里括號中的數(shù)字比如.sct(7)指的就是出錯位置在第7行。你可以打開自己工程的鏈接文件數(shù)一數(shù)是哪一行對應的region報錯。以我前面的示例sct為例第1行: ; ************************************************************* 第2行: ; *** Scatter-Loading Description File generated by uVision *** 第3行: ; ************************************************************* 第4行: 第5行: LR_IROM1 0x08000000 0x00080000 { 第6行: ER_IROM1 0x08000000 0x00080000 { 第7行: *.o (RESET, First) 第8行: *(InRoot$$Sections) 第9行: .ANY (RO) 第10行: .ANY (XO) 第11行: } 第12行: RW_IRAM1 0x20000000 0x00010000 { ...報錯說是第7行對應就是*.o (RESET, First)這一句。所以該行所要求的RESET段缺失。如果你的報錯行號是其他行比如指向LR_IROM1那一行說明整個加載域都有問題可能就是地址重疊或者非法。這個方法能幫你快速確認到底是所有region都沒段匹配還是只有某一個region缺段。這兩種情況的處理邏輯不太一樣——前者通常是啟動文件缺失后者往往是段選擇器的寫法問題。5. 從CubeMX生成工程和舊工程遷移中的特殊雷區(qū)5.1 STM32CubeMX生成的Keil工程為什么也會報L6236E這幾年用CubeMX建工程的人越來越多按理說它生成的工程應該是開箱即用的。但你要是遇到過以下操作照樣會踩到L6236E生成工程后手動把startup_stm32xxxx.s文件從工程里刪了想自己寫啟動邏輯用CubeMX切換了芯片型號但Project Manager → Project里的工具鏈設置沒跟著變或者舊啟動文件沒被覆蓋在.ioc文件里改了Flash/RAM大小但重新生成代碼時勾選了備份舊工程結果新舊啟動文件混雜使用了自己添加的鏈接腳本而CubeMX自動生成的sct被覆蓋了。第一種場景比較難辦。如果你確定不要ST的啟動文件那么你得自己提供一個向量表段并且保證它帶有初始棧指針和復位向量。很多從裸機匯編開始寫固件的老工程師會這么干但對于絕大多數(shù)應用來說直接用官方啟動文件是成本最低、最穩(wěn)妥的方案。第二種場景的處理方法是在CubeMX里重新選擇正確的芯片然后在Project Manager → Linker Settings里確認Heap/Stack大小沒問題最后重新生成代碼讓CubeMX把啟動文件一并刷新。5.2 舊工程換芯片最完整的操作順序如果你手上有個F103C8T6的舊工程要改成F103ZET6千萬別只改Device型號就完事。我的標準操作順序如下你可以直接照著做備份整個工程目錄這一步每次都要做別省Options for Target → Device選擇新芯片Options for Target → Target核對ROM/RAM地址和大小。F103C8T6的RAM是20KB0x20000000大小0x5000Flash 64KB0x08000000大小0x10000換成F103ZET6后RAM是64KB0x10000Flash是512KB0x80000從ST官方固件庫或者另一個正常運行的F103ZET6工程里復制startup_stm32f103xe.s到工程目錄然后在Keil里刪除舊啟動文件、添加新啟動文件檢查C/C選項卡的DefineF103ZE對應STM32F10X_HD標準外設庫或STM32F103xEHAL庫清理編譯產(chǎn)物點Rebuild不是Build是Rebuild。如果還報錯去檢查Linker選項卡里是否勾著Use Memory Layout from Target Dialog確認Scatter File路徑?jīng)]有指向舊芯片的sct。這套流程走下來L6236E基本不會再出現(xiàn)。5.3 使用AC5和AC6編譯器時的啟動文件差異Keil MDK從5.x版本開始默認的編譯器逐漸向Arm Compiler 6基于Clang遷移。AC6和AC5在處理匯編啟動文件上有很多差異這一點會被很多人忽略。AC5使用的armcc/armasm對.s匯編文件的語法比較寬松。而AC6使用的armclang內(nèi)置的匯編器對偽指令的支持不夠全面某些老啟動文件在AC6下會匯編失敗或者產(chǎn)生不同的段屬性。如果你的工程是從AC5遷移到AC6后開始報L6236E優(yōu)先檢查啟動文件是否是比較老、為AC5編寫的版本ST官方針對AC6發(fā)布過新版本的啟動文件CMSIS pack里的通常沒問題在Options for Target → Target → ARM Compiler里嘗試暫時切換回Use default compiler version 5如果能編譯通過說明就是啟動文件對AC6兼容性的問題。從Arm Compiler 5切到6之后很多舊版啟動文件會直接報匯編錯誤不會走到L6236E這一步。但有一種情況是匯編只產(chǎn)生警告沒有報錯最后段的屬性不對才最終在鏈接階段爆炸。5.4 工程路徑和特殊字符的隱患這個方法很少有人提最后分享一個很多人不會第一時間想到的原因工程所在路徑太長或者包含中文、空格、特殊符號。當年我遇到過一個很邪門的L6236E所有的檢查和替換都做完了問題就是復現(xiàn)不了。折騰了一下午最后把整個工程文件夾從D:\工作文件\測試項目\基于STM32的溫控系統(tǒng)_V2_最終版(1)\挪到D:\keil_projects\temp\重新編譯一切正常。原因大概是鏈接器在解析sct里通配符和路徑時對中文字符和多級嵌套目錄的處理在某些編譯器版本里有Bug。雖然這個bug不是每次必現(xiàn)但一旦遇到排查起來極其耗費時間。所以建議你的工程存放路徑盡量滿足全英文不要有空格層級不要超過三四級不要以數(shù)字開頭在某些老版本里也會出問題更不要放在桌面這種權限有時受限的目錄下。6. 實操總結最快的解決路徑和一套順手能用的驗證方法我把上面所有的排查邏輯壓縮成一套可以直接照做的動作建議你按順序執(zhí)行不要跳步。第一步確認啟動文件存在且參與編譯工程樹里有沒有.s文件右鍵.s文件 → Options for File → 確認 Exclude from Build 未勾選。打開.s文件搜索AREA和RESET關鍵字。第二步檢查芯片型號和宏定義Options for Target → Device確認芯片型號。Options for Target → C/C確認Define里有對應型號的宏。如果不確定宏應該是什么去正常能編譯的工程抄一份或者查ST官方模板。第三步重置分散加載文件Options for Target → Linker勾選Use Memory Layout from Target Dialog清除自定義Scatter File路徑。Options for Target → Target確認IROM1起始地址0x08000000大小按芯片F(xiàn)lash實際大小填IRAM1起始0x20000000大小按芯片實際RAM填。Rebuild整個工程。第四步查看詳細鏈接輸出定位Options for Target → Listing勾選Linker Listing下的Memory Map、Cross Reference等。重新編譯后打開.map文件搜索Reset_Handler和__Vectors。如果找不到說明啟動段的產(chǎn)生就有問題回頭檢查匯編文件。也可以用fromelf反匯編.axf文件驗證段地址。第五步整路徑、整編譯器工程路徑改成純英文短路徑。嘗試在Target選項卡里切AC5/AC6判斷是否是編譯器兼容性問題。這套流程我前前后后幫同事處理了不下十次耗時從幾分鐘到一下午都有。但其實九成以上的情況走完第二步就能解決第三步都很少需要用到。再分享一個我自己的習慣**每次新建工程時先不寫任何業(yè)務代碼只放一個main函數(shù)和一個printf重定向確認能在這個工程模板里編譯、下載、跑通串口再往里加功能。**這樣一旦后面報錯你能確定是新增代碼導致的問題而不是工程基礎配置本來就有毛病。L6236E這類鏈接錯誤說白了就是工程配置和實際代碼對不上號你得讓工程底子干凈問題才好定位。