簡(jiǎn)介這份資源是一套基于STM32F103ARM Cortex-M3內(nèi)核的匯編點(diǎn)燈例程工程面向已具備C語言基礎(chǔ)、希望深入理解微控制器底層運(yùn)行機(jī)制的嵌入式學(xué)習(xí)者與工程師。壓縮包共19個(gè)文件、約28KB以Keil5工程文件uvprojx、uvoptx為核心配合匯編源文件與啟動(dòng)文件startup_stm32f10x_md.s、編譯產(chǎn)物axf、o、lst、map、sct、JLink調(diào)試配置與日志以及keilkilll.bat清理腳本等構(gòu)成可直接打開、編譯、下載與在線調(diào)試的完整工程鏈路。程序圍繞GPIO配置與寄存器操作展開涉及R0-R15通用寄存器與SP、LR、PC的使用LDR、STR、MOV、B等指令的加載存儲(chǔ)與分支流程以及GPIOx_MODER、OTYPER、OSPEEDR、PUPDR等寄存器的直接寫入可用于觀察點(diǎn)燈與閃爍循環(huán)的指令級(jí)執(zhí)行過程。已有1653人學(xué)習(xí)下載適合作為匯編入門的第一個(gè)可運(yùn)行樣例也可作為調(diào)試與寄存器驗(yàn)證的參考工程。1. 從一份純匯編的 STM32F103 工程說起為什么還要碰匯編拿到一份純匯編的 STM32F103 工程很多人的第一反應(yīng)是這年頭誰還寫匯編我第一次拆的時(shí)候也是這個(gè)心態(tài)直到要做一個(gè) 2KB 以內(nèi)的最小固件C 編譯出來怎么都塞不下才回頭去啃那份 .s 文件。它用 Keil5 的 armasm 手寫啟動(dòng)代碼、直接懟寄存器點(diǎn)燈、用 SysTick 搭節(jié)拍一行 C 都沒有卻把 Cortex-M3 從上電到跑起來的路子完整走了一遍。這份東西適合兩類人想搞明白向量表、棧頂、分散加載這些“黑匣子”到底怎么排布的底層愛好者以及需要在現(xiàn)成的 C 工程里插一段匯編、做混合編程的開發(fā)者?？炊倩仡^看 C 工程的啟動(dòng)流程很多玄學(xué)問題會(huì)一下子變得可解釋。2. 工程骨架拆解從復(fù)位向量表到主循環(huán)的完整鏈路一個(gè)純匯編工程看著文件少其實(shí)坑全在“哪些文件是必須的、哪些是 Keil5 自動(dòng)生成的”這件事上。先把骨架摸清楚后面編譯報(bào)錯(cuò)才不至于抓瞎。這個(gè)工程的結(jié)構(gòu)大致是這樣文件來源作用startup_stm32f103.s手寫向量表、棧堆定義、Reset_Handlermain.s手寫入口 main、主循環(huán)、業(yè)務(wù)邏輯gpio.s/delay.s手寫GPIO 初始化、延時(shí)函數(shù)可拆可合systick.s手寫SysTick 初始化與中斷服務(wù)程序target.sct手寫或自動(dòng)分散加載決定 Flash/RAM 怎么切project.uvprojx生成工程文件記錄器件型號(hào)、文件分組、編譯選項(xiàng)Objects/*.o、*.hex、*.map生成目標(biāo)文件、固件、地址映射表手寫的那四個(gè).s加一個(gè).sct才是工程的“源碼”剩下的都是構(gòu)建產(chǎn)物刪掉不影響編譯。很多人拿到工程第一眼看到一堆.o、.crf、.uvguix以為都是必需品結(jié)果往 git 里一提交倉(cāng)庫(kù)直接膨脹好幾倍。2.1 啟動(dòng)文件Cortex-M3 上電后的第一段代碼Cortex-M3 復(fù)位后的行為是硬件寫死的從地址0x08000000取第一個(gè)字裝載 MSP取第二個(gè)字裝載 PC。所以啟動(dòng)文件干的第一件事就是把這張表擺到 Flash 的最前面。; startup_stm32f103.s —— 純匯編工程的最小啟動(dòng)文件 Stack_Size EQU 0x00000400 ; 1KB 棧夠用但不鋪張 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_sp ; 標(biāo)簽落在棧的高地址端 PRESERVE8 ; 強(qiáng)制 8 字節(jié)棧對(duì)齊 THUMB ; 后續(xù)代碼按 Thumb 編碼 AREA RESET, DATA, READONLY EXPORT __Vectors __Vectors DCD __initial_sp ; 0x00 初始 MSP DCD Reset_Handler ; 0x04 復(fù)位入口 DCD NMI_Handler ; 0x08 DCD HardFault_Handler ; 0x0C ; ... 中間省略若干系統(tǒng)異常 DCD SysTick_Handler ; 0x3C 系統(tǒng)節(jié)拍 ; ... 后面接外設(shè)中斷本工程只用了 SysTick這里有幾個(gè)點(diǎn)必須理解透否則后面調(diào)試會(huì)很痛苦。DCD是“分配一個(gè)字并填入數(shù)值”它在 Flash 里連續(xù)排布形成的就是那張向量表SPACE只是保留空間不賦初值所以Stack_Mem在鏡像里不占 Flash。__initial_sp這個(gè)標(biāo)簽之所以放在SPACE之后是因?yàn)?Cortex-M3 的棧是“滿遞減”的MSP 必須指向棧的最高地址壓棧時(shí)先減后寫。PRESERVE8容易被忽略——它告訴匯編器在函數(shù)入口保持 8 字節(jié)對(duì)齊AAPCS 要求棧指針在任何函數(shù)調(diào)用邊界都是 8 的倍數(shù)少了這句調(diào)用 C 函數(shù)時(shí)可能在某些浮點(diǎn)或結(jié)構(gòu)體拷貝場(chǎng)景直接掛掉。接著是復(fù)位的跳轉(zhuǎn)邏輯AREA |.text|, CODE, READONLY EXPORT Reset_Handler IMPORT main Reset_Handler PROC LDR R0, main BLX R0 ; 跳進(jìn) main不回來 B . ; 萬一返回就地死循環(huán)方便掛調(diào)試器 ENDPLDR R0, main不是一條真實(shí)指令匯編器會(huì)把它變成從字面量池literal pool取地址再把 main 的絕對(duì)地址裝進(jìn) R0所以這里必須用BLX而不是BL——BL的相對(duì)跳轉(zhuǎn)范圍只有 ±16MB跨段調(diào)用不可靠。B .這個(gè)自跳轉(zhuǎn)看著像湊數(shù)其實(shí)是血淚經(jīng)驗(yàn)一旦 main 意外返回程序停在這里而不是跑飛到隨機(jī)地址調(diào)試器一暫停就能看到 PC 卡在這一行比對(duì)著 HardFault 猜半天強(qiáng)得多。2.2 分散加載文件Flash 和 RAM 的邊界到底誰說了算Keil5 在“Use Memory Layout from Target Dialog”勾選時(shí)會(huì)自動(dòng)生成.sct但純匯編工程最好手寫一份因?yàn)橄蛄勘肀仨毐粡?qiáng)制放到鏡像開頭。; target.sct —— STM32F103C8 的典型布局 LR_IROM1 0x08000000 0x00010000 { ; 加載域64KB Flash ER_IROM1 0x08000000 0x00010000 { ; 執(zhí)行域與加載域同址 *.o (RESET, First) ; 向量表強(qiáng)制排最前 *(InRoot$$Sections) .ANY (RO) ; 其余只讀代碼、常量 } RW_IRAM1 0x20000000 0x00005000 { ; 20KB SRAM .ANY (RW ZI) ; 已初始化變量 零初始化 } }*.o (RESET, First)這一行是整個(gè)文件的核心。它按“段名”而不是文件名來匹配凡是AREA RESET定義的內(nèi)容都會(huì)被拎到最前面所以啟動(dòng)文件里的段名必須寫成RESET寫成RESET_DATA就對(duì)不上。First保證它排在所有內(nèi)容之前這樣0x08000000上一定是棧頂0x08000004上一定是Reset_Handler。RW_IRAM1里的RW ZI決定了兩類數(shù)據(jù)帶初值的全局變量以及需要清零的 BSS 段。這里埋了個(gè)坑——純匯編工程如果不調(diào)用__mainKeil 的 C 庫(kù)初始化流程不會(huì)執(zhí)行RW 段的初值根本不會(huì)從 Flash 搬到 RAM變量上電就是隨機(jī)值。工程里如果只寫寄存器、不用帶初值的全局變量那沒事一旦用了就得自己寫一段搬運(yùn)循環(huán)或者老老實(shí)實(shí)把__main引進(jìn)來。這個(gè)問題在第 5 章會(huì)展開說。2.3 Reset_Handler 到 main 之間還差什么C 工程的Reset_Handler里通常是一句LDR R0, __main由 C 庫(kù)接管棧初始化、RW 搬運(yùn)、BSS 清零最后才BL main。純匯編工程把這套省略了換來的是啟動(dòng)時(shí)間從幾百個(gè)周期降到十幾個(gè)周期代價(jià)是所有初始化都得自己負(fù)責(zé)。我給這個(gè)工程的定位是“最小可用”所以跳過 C 庫(kù)是有意的所有全局狀態(tài)都用寄存器或絕對(duì)地址維護(hù)不給搬運(yùn)環(huán)節(jié)留機(jī)會(huì)。如果要改成能跑 C 的混合工程正確做法是把Reset_Handler改回LDR R0, __main然后在工程里加上 C 庫(kù)的啟動(dòng)文件這一改動(dòng)在最后一章會(huì)具體演示。3. Keil5 環(huán)境搭建把 .s 文件變成能燒進(jìn)片子的固件工程能打開不等于能編譯能編譯不等于能跑。這一章按“裝—配—編—驗(yàn)”的順序走一遍每一步都標(biāo)清楚失敗時(shí)看哪里。3.1 器件支持包與工程選項(xiàng)Device 選錯(cuò)一切白搭Keil5 裝好之后第一件事是裝器件支持包Device Family Pack在 Pack Installer 里找到 Cortex-M3 內(nèi)核對(duì)應(yīng)的 STM32F1 系列裝完重啟 IDE。新建工程時(shí)選STM32F103C8或你手上芯片的具體型號(hào)這一步會(huì)影響三樣?xùn)|西啟動(dòng)文件的默認(rèn)模板、Flash 算法、調(diào)試時(shí)的寄存器視圖。選錯(cuò)了不會(huì)立刻報(bào)錯(cuò)而是燒寫時(shí)提示“Cannot access target”或者擦除失敗非常容易誤判成硬件問題。工程建好后要手動(dòng)確認(rèn)幾個(gè)選項(xiàng)這幾項(xiàng)在純匯編工程里尤其關(guān)鍵選項(xiàng)位置設(shè)置項(xiàng)純匯編工程該選什么Target 頁Use MicroLIB不勾沒有 C 庫(kù)依賴Target 頁Use Memory Layout from Target Dialog取消勾選改用手寫 .sctOutput 頁Create HEX File勾上方便脫機(jī)燒寫Listing 頁Assembler Listing勾上排查地址問題全靠它C/C 頁不需要配置全空Use Memory Layout from Target Dialog取消勾選之后下面的 Scatter File 輸入框才會(huì)激活把target.sct填進(jìn)去。這一步如果漏了Keil 會(huì)按默認(rèn)布局把向量表隨便放0x08000000上就可能不是棧頂程序一上電直接跑飛。3.2 匯編器選項(xiàng)armasm 與 armclang 的語法分水嶺Keil5 從某個(gè)版本開始把默認(rèn)匯編器從 armasm 換成了 armclang 的 GNU 語法前端這直接決定了你手里的.s文件能不能編譯通過。老工程的寫法是AREA、EXPORT、PROC/ENDP新匯編器認(rèn)的是.section、.global、.thumb兩套語法完全不兼容。在 Options for Target → Asm 頁里有一個(gè)Assembler Option下拉選armasm就沿用經(jīng)典語法選armclang就得改源碼。我一般這么做老工程保持 armasm 不動(dòng)省得逐個(gè)文件改新起的工程直接在文件開頭寫.syntax unified走 GNU 路線因?yàn)樾掳姹竟ぞ哝湆?duì) armasm 的支持只會(huì)越來越弱。如果編譯時(shí)出現(xiàn)A1137E: Unexpected characters at end of line或者A1586E: Bad symbol八成就是語法對(duì)不上。判斷方法很簡(jiǎn)單打開.s文件看第一行是;注釋還是注釋;是 armasm和//是 GNU 風(fēng)格。3.3 編譯、下載與在線調(diào)試編譯輸出里最該看的不是 “0 Error(s)”而是最后那行Program Size: Codexxxx RO-dataxxxx RW-dataxxxx ZI-dataxxxx。純匯編點(diǎn)燈工程Code 通常在幾百字節(jié)到 1KB 之間如果突然漲到 4KB 以上說明鏈接器把不該進(jìn)來的東西拉進(jìn)來了多半是.sct里的.ANY匹配范圍太寬。下載配置在 Options → Debug 頁選ST-Link Debugger或CMSIS-DAP點(diǎn) Settings 進(jìn) Flash Download 頁確認(rèn)Programming Algorithm里加的是STM32F10x Med-density Flash對(duì)應(yīng) 64KB/128KB 型號(hào)勾上Reset and Run。這一步翻車最多算法選成 High-density燒寫會(huì)報(bào) “Flash Download failed”因?yàn)椴脸畹牡刂贩秶鷮?duì)不上。調(diào)試階段我習(xí)慣開兩個(gè)窗口——Registers 窗口盯 R13(SP)、R15(PC) 和 xPSRDisassembly 窗口看反匯編。上電復(fù)位后立刻暫停PC 應(yīng)該停在0x08000004附近的Reset_HandlerSP 應(yīng)該是個(gè)0x2000xxxx的值。這兩個(gè)數(shù)不對(duì)后面的代碼寫得再對(duì)也沒用。3.4 用 map 文件核對(duì)固件真的對(duì)編譯完在Objects/或工程根目錄會(huì)生成.map文件這是驗(yàn)證布局的唯一可靠依據(jù)。打開搜Image Entry point應(yīng)該指向Reset_Handler搜__initial_sp應(yīng)該是個(gè) RAM 高地址搜Execution Region ER_IROM1Base 必須是0x08000000。Image Entry point : 0x08000009 ... __initial_sp 0x20000400 Data 4 startup_stm32f103.o(STACK)0x08000009這個(gè)奇數(shù)不是筆誤而是 Thumb 狀態(tài)的標(biāo)志位——Cortex-M3 只支持 Thumb 指令集函數(shù)指針的最低位必須置 1硬件跳轉(zhuǎn)時(shí)會(huì)自動(dòng)清掉。如果 map 里看到入口地址是0x08000008這種偶數(shù)說明某處丟了THUMB屬性跳過去必然進(jìn) HardFault。我第一次遇到時(shí)對(duì)著代碼看了兩小時(shí)最后在 map 文件里找到答案從那以后每次編譯完都先掃一眼這個(gè)值。4. 核心模塊拆解寄存器、延時(shí)與節(jié)拍的三件套骨架搭好之后真正干活的就是三個(gè)模塊GPIO、延時(shí)、SysTick。這三個(gè)加起來不到 100 行匯編但每一條指令的意圖都值得說清楚。4.1 GPIO 直接操作三行代碼點(diǎn)亮一個(gè) LED用 C 的時(shí)候 HAL 庫(kù)把寄存器包裝得嚴(yán)嚴(yán)實(shí)實(shí)寫匯編就沒這層遮羞布了每個(gè)地址都得自己查手冊(cè)。; gpio.s —— PB0 推挽輸出初始化 GPIOB_BASE EQU 0x40010C00 GPIOB_CRL EQU GPIOB_BASE 0x00 ; 端口配置低寄存器 GPIOB_BSRR EQU GPIOB_BASE 0x10 ; 置位/復(fù)位寄存器 RCC_APB2ENR EQU 0x40021018 ; APB2 外設(shè)時(shí)鐘使能 AREA |.text|, CODE, READONLY EXPORT GPIOB_Init THUMB GPIOB_Init PROC LDR R0, RCC_APB2ENR LDR R1, [R0] ORR R1, R1, #(1 3) ; bit3 IOPBEN開 GPIOB 時(shí)鐘 STR R1, [R0] LDR R0, GPIOB_CRL LDR R1, [R0] BIC R1, R1, #0x0000000F ; 清掉 PB0 的 4 位配置 ORR R1, R1, #0x00000003 ; MODE11 輸出 50MHz, CNF00 推挽 STR R1, [R0] BX LR ENDP這里的關(guān)鍵是BICORR這個(gè)組合而不是直接STR一個(gè)常量。GPIOB_CRL一個(gè)寄存器管 8 個(gè)引腳每個(gè)引腳 4 位直接寫常量會(huì)把其他引腳的配置一起沖掉。先BIC清零目標(biāo)位、再ORR置位是寄存器編程的標(biāo)準(zhǔn)做法C 里的 ~mask; | value;編譯出來也是這兩條。時(shí)鐘使能必須放在配置之前這個(gè)順序不能反。RCC_APB2ENR的 bit3 對(duì)應(yīng) GPIOB寫 1 之后外設(shè)才有時(shí)鐘此前的任何寫操作都是無效的。我見過有人把時(shí)鐘使能寫在初始化函數(shù)末尾結(jié)果引腳就是不響應(yīng)查了半天以為是硬件虛焊。點(diǎn)亮 LED 用 BSRR 而不是 ODR因?yàn)?BSRR 是原子操作低 16 位寫 1 置位、高 16 位寫 1 復(fù)位寫 0 的位不受影響。用 ODR 做“讀—改—寫”在中斷環(huán)境下會(huì)被打斷BSRR 不存在這個(gè)問題。; 主循環(huán)里翻轉(zhuǎn) PB0 Loop LDR R0, GPIOB_BSRR LDR R1, 0x00000001 ; BS0置位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms LDR R0, GPIOB_BSRR LDR R1, 0x00010000 ; BR0復(fù)位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms B Loop注意每次BL之前都要重新LDR R0, 500因?yàn)榘?AAPCS 規(guī)定 R0~R3 是調(diào)用者保存寄存器被調(diào)函數(shù)可以隨意改寫。這一點(diǎn)在匯編里沒有任何保護(hù)忘了就等著看 LED 閃得莫名其妙。4.2 軟件延時(shí)一個(gè)雙層循環(huán)的時(shí)序估算沒有定時(shí)器的時(shí)候延時(shí)只能靠空轉(zhuǎn)。這段代碼簡(jiǎn)單但估算方法值得說清楚。; delay.s —— 粗略毫秒延時(shí)入?yún)?R0 毫秒數(shù) Delay_ms PROC PUSH {R1, R2} ; 保存將被改寫的寄存器 LDR R1, 7200 ; 內(nèi)層計(jì)數(shù)見下方估算 Outer MOV R2, R1 Inner SUBS R2, R2, #1 BNE Inner SUBS R0, R0, #1 BNE Outer POP {R1, R2} BX LR ENDP估算邏輯是這樣的72MHz 主頻下SUBSBNE這兩條指令在 Flash 里執(zhí)行約 3~4 個(gè)周期流水線有分支開銷所以要湊 1ms 的 72000 個(gè)周期內(nèi)層計(jì)數(shù)取 7200 左右。這個(gè)數(shù)字是拍腦袋出來的實(shí)際誤差可能到 ±20%因?yàn)?Flash 等待周期、流水線狀態(tài)、中斷搶占都會(huì)影響。想要更準(zhǔn)把內(nèi)層計(jì)數(shù)值調(diào)到 9000 再實(shí)測(cè)一次——用示波器量一個(gè) 100ms 的方波周期反推出實(shí)際系數(shù)。我一般會(huì)在注釋里寫上“實(shí)測(cè) 72MHz / 等待周期 2 時(shí)取 9000”這種具體條件因?yàn)閾Q個(gè)主頻、改個(gè) Flash 等待配置這個(gè)數(shù)字就全變了不寫清楚下次自己都看不懂。PUSH {R1, R2}這兩行不能省。雖然在這個(gè)工程里調(diào)用者恰好沒用到 R1、R2但只要函數(shù)被復(fù)用就可能踩到“被調(diào)函數(shù)悄悄改了寄存器”的坑而這種 bug 往往在改了幾十行之后才爆發(fā)定位成本極高。4.3 SysTick 與中斷向量把節(jié)拍交給硬件軟件延時(shí)占著 CPU 空轉(zhuǎn)想要一邊閃燈一邊干別的就得用 SysTick。; systick.s —— 1ms 系統(tǒng)節(jié)拍 SYST_CSR EQU 0xE000E010 SYST_RVR EQU 0xE000E014 SYST_CVR EQU 0xE000E018 AREA |.text|, CODE, READONLY EXPORT SysTick_Init EXPORT SysTick_Handler IMPORT Tick_Count SysTick_Init PROC LDR R0, SYST_RVR LDR R1, 71999 ; 72MHz / 1000 - 1 STR R1, [R0] LDR R0, SYST_CVR MOV R1, #0 STR R1, [R0] ; 清計(jì)數(shù)器避免首拍不準(zhǔn) LDR R0, SYST_CSR MOV R1, #0x07 ; CLKSOURCE|TICKINT|ENABLE STR R1, [R0] BX LR ENDP SysTick_Handler PROC LDR R0, Tick_Count LDR R1, [R0] ADDS R1, R1, #1 STR R1, [R0] BX LR ENDP0x07這三個(gè)位分別是bit0 使能計(jì)數(shù)器、bit1 使能中斷、bit2 選擇內(nèi)核時(shí)鐘不選的話走 HCLK/8。LOAD值等于重裝載值計(jì)數(shù)器從 LOAD 遞減到 0 觸發(fā)中斷所以 1ms 要填 71999 而不是 72000。SysTick_Handler這個(gè)名字必須和向量表里DCD的那一項(xiàng)完全一致而且必須EXPORT否則鏈接器看不到向量表里那一項(xiàng)會(huì)被填成 0中斷一觸發(fā)就跳進(jìn) HardFault。這是純匯編工程最常見的問題之一比 C 工程更容易犯因?yàn)?C 里通常有統(tǒng)一的stm32f1xx_it.c兜底匯編里沒有。中斷服務(wù)程序的返回值必須用BX LR不能用POP {PC}或者B回跳。異常返回時(shí)硬件會(huì)從棧里恢復(fù) R0~R3、R12、LR、PC、xPSRBX LR里那個(gè)特殊值0xFFFFFFF9就是告訴內(nèi)核“走異常返回流程”。5. 避坑與排查匯編工程里最容易翻車的五處匯編不像 C編譯器不會(huì)幫你兜任何東西錯(cuò)了就是錯(cuò)了而且錯(cuò)誤現(xiàn)象往往離真正的原因很遠(yuǎn)。下面五條都是我在實(shí)際調(diào)試中撞過的按“現(xiàn)象—原因—解決”整理。5.1 編譯報(bào) Undefined symbol但函數(shù)明明寫了現(xiàn)象編譯時(shí)報(bào)A1137E: Undefined symbol SysTick_Handler可文件里確實(shí)有SysTick_Handler PROC。原因PROC/ENDP只是標(biāo)記函數(shù)邊界不改變符號(hào)的可見性跨文件引用必須顯式EXPORT。反過來的情況也常見——在本文件里用IMPORT聲明的符號(hào)如果實(shí)際定義處沒EXPORT鏈接一樣失敗。解決所有會(huì)被向量表DCD引用、或者被其他.s文件BL的函數(shù)一律加EXPORT 函數(shù)名。習(xí)慣做法是在每個(gè).s文件頭部集中放一組EXPORT比散落在函數(shù)前面更容易查。5.2 燒寫成功但不運(yùn)行PC 停在莫名其妙的地方現(xiàn)象Flash 下載顯示成功按復(fù)位鍵什么都沒發(fā)生調(diào)試器暫停后 PC 指向0x08000000或者某個(gè)非法地址。原因向量表沒被放到鏡像開頭。要么.sct里漏了*.o (RESET, First)要么啟動(dòng)文件里的AREA段名寫成了別的比如RESET_DATA導(dǎo)致鏈接器匹配不上向量表被當(dāng)成普通只讀數(shù)據(jù)排到了后面。解決打開.map文件搜Image Entry point正常應(yīng)該是0x08000009這種奇數(shù)。如果 Base 不是0x08000000回到.sct逐字核對(duì)段名。另外確認(rèn) Options 里Use Memory Layout from Target Dialog已取消勾選否則手寫.sct根本不生效。5.3 全局變量上電是隨機(jī)值現(xiàn)象定義了一個(gè)帶初值的全局計(jì)數(shù)變量期望上電從 0 開始實(shí)際讀到的是亂碼。原因純匯編工程沒有調(diào)用__mainKeil 的 C 庫(kù)初始化流程沒跑RW 段的初值還在 Flash 里躺著沒被搬進(jìn) RAM。.sct寫的RW只是告訴鏈接器“這塊地址歸你”不代表會(huì)有人去搬運(yùn)。解決要么在Reset_Handler里手寫一段搬運(yùn)循環(huán)從Load$$RW_IRAM1$$Base拷到Image$$RW_IRAM1$$Base長(zhǎng)度取Image$$RW_IRAM1$$Length要么干脆不用帶初值的全局變量全部用寄存器傳參。我選后者因?yàn)榧儏R編工程的定位就是“極簡(jiǎn)”為了一個(gè)變量引入散加載搬運(yùn)不劃算。5.4 LDR 偽指令編譯報(bào)錯(cuò)或取到錯(cuò)誤地址現(xiàn)象LDR R0, 0x40021018報(bào)A1516E: Immediate too large或者編譯通過了但取到的值不對(duì)。原因LDR Rd, expr是偽指令匯編器會(huì)把它變成 PC 相對(duì)的字面量加載。字面量池默認(rèn)放在當(dāng)前段末尾或者下一個(gè)LTORG處如果池子距離指令超過 4KBThumb 的 PC 相對(duì)尋址范圍匯編器就報(bào)錯(cuò)。解決在兩個(gè)函數(shù)之間手動(dòng)插一行LTORG強(qiáng)制在此處傾倒字面量池。大段代碼中間隔幾百行就補(bǔ)一個(gè)不要指望匯編器自動(dòng)處理。另一個(gè)辦法是用MOVW/MOVT組合直接構(gòu)造 32 位常量不依賴字面量池代價(jià)是占兩條指令。5.5 單步調(diào)試時(shí)一進(jìn)中斷就掉 HardFault現(xiàn)象主循環(huán)跑得好好的一開中斷立刻進(jìn) HardFault棧里翻出來的 PC 指向向量表某個(gè)空項(xiàng)。原因中斷服務(wù)程序沒EXPORT或者名字和向量表里的DCD不一致鏈接器把這個(gè)符號(hào)當(dāng)成未定義向量表對(duì)應(yīng)位置填了 0。還有一種情況是處理函數(shù)里用了 R4~R11 卻沒PUSH異常返回后主流程的寄存器被改壞。解決把所有中斷處理函數(shù)集中在一個(gè)文件里向量表的DCD列表和函數(shù)定義一一對(duì)照著看。處理函數(shù)里只碰 R0~R3 和 R12硬件自動(dòng)保存要用 R4 以上必須PUSH {R4, LR}、結(jié)尾POP {R4, PC}用POP {PC}一樣能觸發(fā)異常返回還省一條指令。6. 二次開發(fā)把匯編模塊掛進(jìn) C 工程純匯編跑通了實(shí)際項(xiàng)目里更常見的是反過來——主體用 C只有某幾個(gè)對(duì)時(shí)序或體積極其敏感的函數(shù)用匯編寫。這時(shí)候要做的是混合編程關(guān)鍵是守住 AAPCS 那套調(diào)用約定。最省事的做法是保留 C 工程的啟動(dòng)文件和__main把匯編文件當(dāng)成一個(gè)普通模塊加進(jìn)分組。匯編側(cè)要做的就兩件事EXPORT出去給 C 調(diào)IMPORT進(jìn)來調(diào) C。; crc16.s —— 給 C 工程提供 CRC16 查表加速函數(shù) AREA |.text|, CODE, READONLY EXPORT crc16_asm ; C 側(cè)聲明 extern uint16_t crc16_asm(...) THUMB ; uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len) ; 入?yún)0crc, R1buf, R2len 返回R0 crc16_asm PROC PUSH {R4, LR} ; 只用到 R4順手把 LR 也壓了 CMP R2, #0 BEQ done loop LDRB R3, [R1], #1 ; 取一字節(jié)并后自增 EOR R3, R3, R0, LSR #8 LDR R4, crc_table ; 表在 C 側(cè)定義并 extern LDRH R3, [R4, R3, LSL #1] ; 半字索引偏移 idx*2 EOR R0, R3, R0, LSL #8 SUBS R2, R2, #1 BNE loop done UXTH R0, R0 ; 只保留低 16 位 POP {R4, PC} ENDP這段代碼里幾個(gè)點(diǎn)必須對(duì)上入?yún)㈨樞蚴?R0、R1、R2返回值放 R0PUSH {R4, LR}保證 8 字節(jié)對(duì)齊兩條寄存器正好 8 字節(jié)同時(shí)保住 R4 和返回地址POP {R4, PC}一次完成恢復(fù)和返回。C 側(cè)只需要一句extern uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len);鏈接時(shí)把.s和.c一起編進(jìn)去就行。驗(yàn)證方法我固定用三步先用 C 寫一份參考實(shí)現(xiàn)跑同一組測(cè)試向量對(duì)比結(jié)果再用調(diào)試器看匯編函數(shù)的入口處 R0~R2 是否等于 C 傳進(jìn)來的值不等就是參數(shù)傳遞出了問題最后在函數(shù)返回后檢查 R4 有沒有被改回去寄存器窗口里對(duì)比調(diào)用前后的值。這三步走完混合編程基本不會(huì)再出問題。從那以后我每次往 C 工程里塞匯編函數(shù)都會(huì)先在注釋里把入?yún)⒓拇嫫?、返回值寄存器、?huì)破壞哪些寄存器寫清楚再讓 C 側(cè)調(diào)用一次并對(duì)比參考實(shí)現(xiàn)——省下的這點(diǎn)時(shí)間遠(yuǎn)不如后面定位一個(gè)“R4 被悄悄改掉導(dǎo)致主流程跑飛”的代價(jià)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取