简介：ARM Compiler v5.05 Build 169 是面向嵌入式开发者的编译器更新包，适用于使用 Keil MDK 等 ARM Compiler 5 工具链的工程师，用于替换或升级旧版编译器，解决工程编译兼容性与版本匹配问题。压缩包共 3 个文件，包含 exe 安装引导程序、msi 主安装包以及 html 格式的版本说明文档，整体约 79.71MB，安装前可先阅读说明了解版本变更与授权要求。该更新需配合 ARM Compiler 5 产品的有效许可证使用，且不适用于更新 ARM DS-5 中的编译器；同一功能版本的多份更新（如 5.01u1 与 5.01u2）不支持共存于同一台机器，但不同版本号的功能版本可并行安装。目前已有 2404 人学习下载，适合需要稳定编译环境、排查旧工程构建问题的嵌入式开发者参考使用。

1. 老工程迁移绕不开的那套 ARM 编译器：它到底解决什么问题

手上有个跑了七八年的嵌入式工程，Keil 里点开魔术棒，Target 页的编译器版本写着 “Use default compiler version 5”，换台新机器一编译，满屏error: #5: cannot open source input file "core_cm3.h"，或者干脆提示找不到ARMCC。这时候你需要的不是升级，而是把 ARM Compiler v5.05 Build 169 这套老工具链原样装回去。它属于 ARM 自家第五代编译器，也就是大家嘴里常说的 ARMCC，配套 armasm、armlink、fromelf 一整套，专治老工程、老启动文件、老分散加载脚本在新环境下的水土不服。适合谁？维护存量 Cortex-M 项目、要复现别人给的 Keil 工程、或者做课程设计必须对齐指定工具链的从业者和学生。这篇就按“装得上、编得过、查得清”的顺序拆一遍。

2. 先搞懂 ARMCC 5 与 ARMCC 6 的差别：为什么不能直接换

很多人第一反应是“编译器不都差不多，装个新的不就行了”。真上手就会发现，ARM Compiler 5 和 6 是两套几乎不兼容的工具链：5 基于 ARM 自己的编译器前端，6 换成了基于 LLVM/Clang 的 armclang。语法扩展、内联汇编写法、启动文件、链接脚本格式全都不一样。老工程里大量__asm块、__attribute__((at(...)))、分散加载.sct文件，在 6 下要么报错要么行为漂移。所以选型理由很直接：工程原本用哪代编译器，就装回哪代，别在迁移工具链上浪费调试时间。

2.1 两代工具链的关键差异对照

先把差异摆清楚，你才知道哪些地方会翻车。下面这张表是我对照老工程实际编译日志整理的，不是官方文档抄来的：

看到没，光是内联汇编这一项，老代码里几十处__asm块在 6 下全部要重写。这就是为什么维护存量项目时，装回 5.05 是最省事的路。

2.2 安装目录与工具链注册

ARM Compiler 5.05 装完后，核心可执行文件在安装目录的bin下，典型路径形如C:\Keil_v5\ARM\ARMCC\bin。里面几个关键程序：

• armcc.exe：C 编译器
• armasm.exe：汇编器，处理.s启动文件
• armlink.exe：链接器，吃.sct分散加载脚本
• fromelf.exe：把.axf转成.bin/.hex，产线烧录要用
• armar.exe：静态库打包

装好后 Keil 不会自动认，得在魔术棒里手动指过去。Target 页把 “Use default compiler version” 改成指定版本，或者在Options for Target → Target → ARM Compiler下拉里选到 5.05。如果下拉里没有，说明安装时没注册进 Keil 的TOOLS.INI，得手动补一行路径。

提示：装之前先确认工程原来用的就是 5.x。打开旧工程的.uvprojx，搜pCCUsed字段，值里带5.05就对了，别凭感觉装。

2.3 用命令行先验证工具链是否可用

别急着开 Keil 图形界面，先在命令行把工具链跑通，能省掉一半“到底是环境问题还是代码问题”的扯皮。打开 CMD，进到bin目录：

# 查看编译器版本，确认装的是 5.05 build 169 armcc --version # 预期输出类似： # Product: ARM Compiler 5.05 # Component: ARM Compiler 5.05 update 1 (build 169) # Tool: armcc [4d0efa4]

版本号对上了，再拿一个最小 C 文件试编译：

# 编译一个空 main，只验证工具链本身能跑 armcc --c99 -c test.c -o test.o # 链接成 axf，不指定分散加载，用默认布局 armlink test.o -o test.axf # 转 bin，验证 fromelf 也正常 fromelf --bin test.axf -o test.bin

这三步全过，说明编译器、链接器、格式转换器都活着。哪一步报not recognized as an internal command，就是 PATH 没配或安装不完整；报cannot open就是文件路径有中文或空格。命令行通了再回 Keil，问题范围立刻缩小到工程配置层面。

3. 把老工程接进 5.05：工程配置与分散加载实战

工具链装好只是第一步，真正花时间的是让老工程在新装的 5.05 下编得过。这一章按“工程选项 → 头文件路径 → 分散加载 → 启动文件”的顺序走，每一步都给出可对照的配置和排错点。

3.1 工程选项里必须对齐的四个地方

Keil 的 Options for Target 有四个页签跟编译器强相关，逐个过：

Target 页：ARM Compiler 选 5.05；勾选 “Use MicroLIB” 要看原工程是否依赖，老工程如果用了printf重定向到串口，通常勾了 MicroLIB，别乱取消。

C/C++ 页：Define里的宏（如STM32F10X_HD、USE_STDPERIPH_DRIVER）必须和原工程一致，少一个宏就可能编出一堆undefined。Include Paths要把标准外设库、CMSIS、用户头文件目录全列上。

Asm 页：如果启动文件是.s，这里要确认Define和 C 页保持一致，否则汇编里的条件编译会走错分支。

Linker 页：这是重灾区。勾 “Use Memory Layout from Target Dialog” 表示用 Keil 自动生成的分散加载；如果原工程带了自定义.sct，要取消勾选并在 “Scatter File” 里指过去。

// 典型的老工程 C 页宏定义，少一个都编不过 // Define 栏填： // STM32F10X_HD,USE_STDPERIPH_DRIVER

宏定义这块没有捷径，只能对着原工程的.uvprojx逐字比对。我一般会把新旧两份工程文件用文本对比工具拉出来，只盯Define、IncludePath、ScatterFile三个字段，差异一目了然。

3.2 分散加载脚本的写法与常见错位

分散加载.sct决定代码和数据落在哪块 Flash/RAM。老工程常见的手写脚本长这样：

; 典型 Cortex-M3 分散加载，Flash 起始 0x08000000，RAM 起始 0x20000000 LR_IROM1 0x08000000 0x00080000 { ; 加载域：512KB Flash ER_IROM1 0x08000000 0x00080000 { ; 执行域：代码放 Flash *.o (RESET, +First) ; 中断向量表必须放最前 *(InRoot$$Sections) .ANY (+RO) ; 其余只读段 } RW_IRAM1 0x20000000 0x00010000 { ; 读写段放 64KB RAM .ANY (+RW +ZI) } }

几个参数必须和芯片实际容量对上：0x00080000是 512KB，0x00010000是 64KB，写大了链接器不报错但运行会跑飞，写小了直接L6406E: No space in execution regions。RESET, +First这行保证向量表落在 0x08000000，漏了它程序上电第一条指令就错。

注意：.sct里的地址和大小是十六进制，别把 512KB 写成0x80000之外的值。改完脚本一定要重新全编译，增量编译不会重新跑链接布局。

3.3 启动文件与向量表的对齐检查

启动文件startup_stm32f10x_hd.s这类 ARM 汇编文件，在 5.05 下由armasm处理。最容易出的问题是栈顶地址和向量表偏移：

; 启动文件开头，栈大小和堆大小按工程实际 RAM 调整 Stack_Size EQU 0x00000400 ; 1KB 栈，中断嵌套深就加大 AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE Stack_Size __initial_sp Heap_Size EQU 0x00000200 ; 512B 堆，用 malloc 才需要 AREA HEAP, NOINIT, READWRITE, ALIGN=3 __heap_base Heap_Mem SPACE Heap_Size __heap_limit

Stack_Size给小了，中断一嵌套就 HardFault，现象是“跑着跑着就死”，很难查。我一般先给 1KB，跑压力测试再调。Heap_Size如果工程根本不用malloc，给 0 都行，省 RAM。启动文件里的Reset_Handler会调SystemInit再跳__main，这条链路任何一环名字对不上，链接阶段就报undefined symbol。

3.4 编译产物验证：从 axf 到 bin 的完整链路

编过不等于对。链接完成后要验证产物：

# 查看 axf 的段布局，确认代码落在 Flash、数据落在 RAM fromelf --text -c project.axf | more # 生成 bin 供烧录，注意起始地址要和分散加载一致 fromelf --bin --output project.bin project.axf # 查看镜像大小，和 Flash 容量对比留余量 fromelf --text -z project.axf

--text -c输出各段起始地址和大小，重点看ER_IROM1的 Load Region 起始是不是 0x08000000，RW_IRAM1是不是 0x20000000。--bin生成的 bin 默认从最低加载地址开始，如果分散加载里 Flash 不从 0x08000000 起，bin 的偏移会不对，烧进去跑飞。这一步是很多“编译成功但板子不跑”的根因。

4. 避坑与排查：五条血泪经验

这一章全是实际踩过的坑，按“现象 → 原因 → 解决”写，照着对号入座能省不少时间。

4.1 报 cannot open source input file “core_cm3.h”

现象：编译一开始就报找不到 CMSIS 头文件，明明目录里就有。

原因：Include Paths 里写的是绝对路径，换机器后路径变了；或者路径里有中文、空格，armcc 解析失败。

解决：全部改成相对工程文件的路径，如..\Libraries\CMSIS\CM3\CoreSupport；路径里杜绝中文和空格。改完 Clean 再全编译，增量编译会缓存旧路径。

4.2 链接报 L6406E: No space in execution regions

现象：代码量没超，链接却说过空间不足。

原因：分散加载里 RAM 或 Flash 大小写小了，或者RW_IRAM1的起始地址和芯片实际 RAM 起点差了一截（比如把 0x20000000 写成 0x2000000）。

解决：对照芯片手册核对起始地址和容量，十六进制位数数清楚。改完看fromelf --text -z的实际占用，留 10% 余量。

4.3 程序烧进去不跑，复位后停在 HardFault

现象：编译链接全过，烧录成功，上电没反应或进 HardFault。

原因：向量表没放最前（.sct漏了RESET, +First），或者启动文件里的栈顶地址和实际 RAM 不匹配。

解决：检查.sct第一行执行域是否含*.o (RESET, +First)；用调试器看复位后 PC 是否落在 0x08000000 附近，SP 是否在 RAM 顶端合理范围。

4.4 内联汇编报错 unknown register name

现象：老代码里的__asm块在 5.05 下报寄存器名不认识。

原因：代码其实是从 ARMCC 6 或 GCC 迁过来的，用了asm("...")语法，5.05 不认。

解决：改回__asm { ... }块语法，寄存器用r0、r1这种 ARMCC 5 认的写法。改之前先确认这段汇编是不是必须的，能用 C 替就替掉。

4.5 Keil 下拉里找不到 5.05 版本

现象：装完了，Options 里 ARM Compiler 下拉只有 6，没有 5.05。

原因：安装时没写进 Keil 的TOOLS.INI，或者装到了非默认目录。

解决：打开 Keil 安装目录下的TOOLS.INI，在[ARM]段手动加一行PATH="C:\Keil_v5\ARM\ARMCC\bin"，重启 Keil。路径指向bin目录，不是ARMCC根目录。

5. 进阶：用批处理固化编译流程与版本校验

图形界面点多了容易漏配置，尤其是团队协作时每个人机器上的 Keil 设置还不一样。我的习惯是把编译流程固化成批处理，每次构建前先校验编译器版本，版本不对直接退出，避免“在我机器上能编”的扯皮。

@echo off REM 构建前强制校验 ARMCC 版本，防止误用 6.x 编老工程 set ARMCC_BIN=C:\Keil_v5\ARM\ARMCC\bin "%ARMCC_BIN%\armcc.exe" --version | findstr "5.05" >nul if errorlevel 1 ( echo [ERROR] ARM Compiler 版本不是 5.05，终止构建 exit /b 1 ) REM 全量清理后重新编译，避免增量缓存干扰 del /q Objects\*.o 2>nul "%ARMCC_BIN%\armcc.exe" --c99 -c Src\main.c -o Objects\main.o "%ARMCC_BIN%\armcc.exe" --c99 -c Src\system.c -o Objects\system.o "%ARMCC_BIN%\armasm.exe" --cpu Cortex-M3 Src\startup.s -o Objects\startup.o REM 链接并生成 bin，分散加载脚本显式指定 "%ARMCC_BIN%\armlink.exe" Objects\*.o --scatter=project.sct -o Objects\project.axf "%ARMCC_BIN%\fromelf.exe" --bin --output Objects\project.bin Objects\project.axf echo [OK] 构建完成，产物在 Objects 目录

这段脚本的关键在开头三行：findstr "5.05"做版本门禁，errorlevel 1捕获不匹配。--cpu Cortex-M3要和芯片内核一致，M0 就写Cortex-M0，写错汇编器会按错误指令集生成。--scatter显式指定脚本，不依赖 Keil 自动生成，团队里谁跑结果都一样。

再补一个产物自检的小技巧：构建完用fromelf --text -z把镜像大小抓出来，和 Flash 容量做比值，超过 85% 就在脚本里打警告。老工程加功能最容易悄悄把 Flash 撑爆，等烧录失败才发现就晚了。

REM 抓取镜像总大小，和 512KB Flash 对比 for /f "tokens=*" %%i in ('"%ARMCC_BIN%\fromelf.exe" --text -z Objects\project.axf ^| findstr "Total RO"') do echo %%i

这套流程跑顺之后，换机器、换人接手，只要批处理能过，工程就是可复现的。从那以后我每次接老工程，第一件事不是打开 Keil，而是先在命令行把armcc --version和批处理跑一遍，版本和产物都对上，才动代码。希望帮到你。

本文还有配套的精品资源，点击获取