ARMCC 5.06安装与AC5老工程编译避坑指南

简介：这份 ARM Compiler 5.06(960) 工具包面向仍在使用旧版 ARMCC 工具链的嵌入式工程师、Keil MDK 项目维护者及相关课程学习者，主要用于老工程编译、版本兼容性排查与基于 ARM 架构的固件开发，也适合教学实验复现和版本回退场景。压缩包共 3 个文件，包含 Windows x86 安装程序、版本说明网页和安装引导程序，整体约 80.52MB，安装后可在本地完成编译器部署，并查阅该版本的更新记录、修复项与已知问题。已有 3607 人学习或下载。读者可重点了解 armcc 对 ANSI C 的兼容支持、代码大小与运行速度优化选项、Thumb/Thumb-2 多目标编译能力，以及它与 Keil 调试工具链配合的流程；版本说明有助于评估从旧工程迁移时的风险，安装程序则能减少环境搭建与配置成本，并帮助排查因工具链差异导致的编译错误，适合需要稳定复现经典编译环境的嵌入式项目。

1. armcc 5.06 安装包：为什么还有工程指定它

接手一块十年前量产的工控板，工程目录里是startup.s、散列加载文件、几个只有.lib没有源码的驱动库。换成新编译器，第一轮编译就无法继续：汇编器语法不认AREA，库文件直接报 ABI 不匹配。这时继续迁移的代价是重新验证整机时序，而把编译器版本恢复回来只需要十分钟。ARMCompiler_506_Windows_x86_b960.msi就是为这件事准备的：ARMCC 5.06 build 960 的 Windows 32 位安装包，安装完成后会得到armcc、armasm、armlink、armar、fromelf一整套命令行工具，既能让 Keil 调用，也能脱离 IDE 单独跑 Makefile。适合维护存量 ARM7/ARM9/Cortex-M 工程、需要复现历史固件、被 AC6 迁移卡住又想先出包的人；不适合从零起的新项目。

2. 先分清 AC5 和 AC6：哪些工程必须退回 armcc 5.06

2.1 两代编译器的技术分界线

ARMCC 5.x 是基于 EDG 前端的商业编译器，armclang（AC6）换成了 Clang/LLVM 前端。这不只是“换个壳”，从语言标准到汇编语法到运行时库，两层都变了。很多人以为改个--cpu就能过，结果卡在汇编文件上——这是最常见的误判。

关键结论只有一条：AC5 产出的.o与 AC6 产出的.o不能混链。你会看到L6200E: Symbol multiply defined或者更隐晦的 “incompatible object” 报错，这时候不要去改链接脚本，先把 build 目录整个删掉重编。混合链接是这类工程里最常见的“虚假 bug”。

另外一个容易被忽略的点是--apcs。老工程里经常写着--apcs=/interwork，AC6 不认这个选项；反过来 AC6 的-fshort-enums语义与 AC5 也不同。判断依据不是“哪个新”，而是“你的.lib是谁编的”。

2.2 MSI 里到底装了什么

这个包是标准的 Windows Installer 封装，安装完成后落到磁盘上的目录结构大致如下，认识它比记住安装向导点了几次“下一步”有用得多。

bin/下全是 32 位可执行文件，意味着在 64 位 Windows 上依赖 WoW64 子系统。绝大多数机器没问题，但在某些精简过的系统镜像里会直接“闪退无输出”，这时候先确认C:\Windows\SysWOW64\是否完整，而不是怀疑安装包损坏。

安装路径建议是纯 ASCII、无空格、层级短，例如C:\tools\ARMCC506。装到Program Files (x86)不是不行，但后面写 Makefile 时每一处路径都要加引号，一个漏加就报cannot open file，排查成本远高于换个目录。

2.3 判定清单：你的工程该不该用 5.06

不要凭感觉决定。下面五条里中两条以上，退回 AC5 通常是更划算的选择；一条不中，就该老老实实迁移到 AC6。

反过来，如果你的工程是纯 C、无汇编、第三方库都有源码、也没有认证包袱，那就别折腾了，直接用 AC6，别为了“怀旧”给自己加一道维护成本。工具链选型的本质是成本比较，不是版本崇拜。

3. 装完能用：MSI 静默安装、PATH 配置与 Keil 接管

3.1 静默安装与安装日志

图形向导点完就忘，出了问题没有任何线索。装这类老工具链，我习惯直接走msiexec并留下日志，后面无论成功失败都有据可查。

:: 静默安装到自定义目录，并生成详细日志 msiexec /i "ARMCompiler_506_Windows_x86_b960.msi" /qn /norestart ^ INSTALLDIR="C:\tools\ARMCC506" ^ /L*v "%TEMP%\armcc506_install.log" :: 安装完先看返回码，0 才是成功 echo %ERRORLEVEL%

命令逻辑很简单：/qn关掉所有交互界面，/norestart阻止安装器自行重启，/L*v输出最详细的日志。INSTALLDIR这个属性名在部分 MSI 包里叫INSTALLROOT或TARGETDIR，如果安装完发现文件落在默认路径，说明属性名没被识别——打开日志搜Property(S):就能看到它实际认了哪个键。

返回码不是 0 的时候不要急着重装，先看日志尾部。1603通常是权限问题，用管理员身份重跑；1605表示产品未安装，说明上一次其实没装上；3010是成功但需要重启，可以忽略。

安装完成后做一次文件核对，比在 IDE 里瞎点快得多：

dir /b "C:\tools\ARMCC506\bin\armcc.exe" "C:\tools\ARMCC506\bin\armlink.exe" "C:\tools\ARMCC506\bin\fromelf.exe"

三个都在，说明核心组件完整。少一个就是安装包没解全，重装。

3.2 环境变量与命令行自检

装完之后第一件事不是打开 Keil，而是在一个干净的 cmd 窗口里验证编译器本身能跑。这一步能把“安装问题”和“工程问题”彻底分开。

:: 只对当前窗口生效，避免污染全局 PATH set ARMCC5=C:\tools\ARMCC506 set PATH=%ARMCC5%\bin;%PATH% :: 确认版本号，输出里应能看到 5.06 与 build 960 armcc --version :: 编一个最小文件，验证头文件路径和代码生成 armcc -c --cpu Cortex-M3 -O2 -I"%ARMCC5%\include" hello.c -o hello.o :: 反汇编看一眼，确认产物是 Thumb 指令 fromelf --text -c hello.o

--cpu Cortex-M3决定了指令集、默认宏和链接时选哪个运行库，写错不会报错，但生成的指令对不上目标核，跑起来就是硬件异常。-I必须显式指向include，因为这套命令行工具不会自己去猜头文件位置——这和 IDE 里“新建工程就能编”的体验完全不同，是新手第一道坎。

fromelf --text -c的输出里如果出现0x0000开头的地址和MOVS、LDR这类 Thumb 指令，说明代码生成正常。看到ARM指令或一片空白，回去检查--cpu。

3.3 让 Keil 接管这个编译器

较新的 MDK 版本已经不再随包附带 AC5，必须单独安装再在 IDE 里指定路径。有两种做法，我一般两种都做，防止换机器时踩空。

第一种是改TOOLS.INI。找到 uVision 安装目录下的这个文件，先备份，然后在[ARM]段里把PATH指到编译器根目录：

[ARM] PATH="C:\tools\ARMCC506"

第二种是在 IDE 里走菜单：Project → Manage → Project Items → Folders/Extensions，在工具链列表里把 ARM Compiler 的根目录指过去。改完重启 uVision，在Options for Target → Target页的编译器下拉里就能看到 5.06。

选完之后不要只看下拉框显示什么，去Options for Target → Listing里打开汇编列表，编一次，看列表头的编译器版本行。下拉框可以骗人，listing 不会。

3.4 一个能直接抄的最小工程

IDE 适合调试，但出包和 CI 必须走命令行。下面这份 Makefile 是一个能跑通 C + 汇编 + scatter 的最小骨架，把这几个变量换成你自己的文件就能用。

# 最小可编译工程骨架：Cortex-M3 + AC5.06 CC := armcc AS := armasm LD := armlink FROMELF := fromelf CPU := --cpu Cortex-M3 INC := -I./inc -I"C:/tools/ARMCC506/include" CFLAGS := $(CPU) -c -O2 --apcs=interwork --split_sections $(INC) LDFLAGS := $(CPU) --scatter fw.sct --map --info sizes,totals OBJS := startup.o main.o board.o TARGET := fw.axf all: $(TARGET) fw.bin # C 源文件统一规则 %.o: %.c $(CC) $(CFLAGS) $< -o $@ # 汇编启动文件必须走 armasm，不能交给 armcc startup.o: startup.s $(AS) $(CPU) --pd "USE_STDPERIPH_DRIVER SETA 1" startup.s -o $@ # 链接：顺序无关，但 scatter 必须存在 $(TARGET): $(OBJS) fw.sct $(LD) $(LDFLAGS) $(OBJS) -o $@ # 从 axf 提取裸 bin fw.bin: $(TARGET) $(FROMELF) --bin --output=$@ $< clean: -del /q *.o *.axf *.bin *.map 2>nul

几个参数值得单独说。--apcs=interwork让函数同时支持 ARM 与 Thumb 互调，老工程里几乎是默认值，缺了它会在跨状态调用时崩。--split_sections把每个函数放进独立段，配合链接器的--remove能删掉未被引用的函数，对 Flash 紧张的板子是实打实的收益。--info sizes,totals会在 map 文件里打印各段的汇总尺寸，出包前扫一眼就知道有没有超。

注意 Makefile 里的缩进必须是真正的 Tab，从网页复制过去常常被替换成空格，报missing separator就是这个原因。

4. 编译与链接参数：-O2、--split_sections 和 scatter 的实际取舍

4.1 优化级别不是越高越好

同一个工程换个-O就行为异常，是嵌入式里最典型的“玄学”现场。原因不神秘：优化器会重排、内联、删除它认为无副作用的代码，而裸机代码里大量“看起来没副作用”的东西其实在等硬件。

血泪经验集中在延时函数上。下面这段代码在-O0下工作正常，-O2下直接失效：

/* 反例：循环变量不是 volatile，整个循环会被优化器删掉 */ void delay_bad(void) { for (int i = 0; i < 1000; i++) { /* 空循环 */ } } /* 稳定写法：volatile 计数，配合 __nop 防止被合并 */ void delay_good(uint32_t n) { volatile uint32_t i; for (i = n; i > 0; i--) { __nop(); } }

volatile告诉编译器“这个变量可能在别处被改”，逼它每次真读内存，循环因此保留。__nop()是编译器内建，不会引入函数调用开销。这类问题的排查方法很土但有效：把可疑函数单独拿出来，分别用-O0和-O2编一次，用fromelf --text -c对比反汇编，函数体凭空消失就是被优化掉了。

4.2 告警治理：别用抑制掩盖问题

老工程一开编就是几百条告警，很多人的第一反应是全局--diag_suppress一把梭。这样做的问题在于，被抑制的告警里往往混着真问题。我的做法是先分类，只抑制确认无害的。

:: 只抑制已确认无害的三类，其余保留 armcc -c --cpu Cortex-M3 -O2 ^ --diag_suppress=177,1295,188 ^ -I./inc main.c -o main.o

177-D是“变量声明未使用”，在包含大量条件编译的驱动头文件里几乎必然出现，抑制掉合理。1295-D是弃用声明提示，老库常见。188-D是枚举与整型混用，裸机寄存器操作里到处都是。除了这三类，其他告警建议保留，尤其是#1-D（最后一行无换行）之外的语法类提示。

如果只想在某个文件里抑制，用源码内的 pragma 更精准：

/* 只在这个编译单元内抑制，不影响整个工程 */ #pragma diag_suppress 177 #include "legacy_driver.h" #pragma diag_default 177

#pragma diag_default把告警恢复成默认状态，避免影响后续包含的文件。这种成对写法比全局开关安全得多。

4.3 scatter file：段放在哪比代码写什么更影响成败

分散加载文件决定了代码和数据落到哪块物理存储。写错不会编译报错，但运行必崩，属于“黑匣子”级别的坑。

LR_IROM1 0x08000000 0x00040000 { ER_IROM1 0x08000000 0x00040000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00010000 { .ANY (+RW +ZI) } }

RESET, +First保证中断向量表落在 Flash 起始地址，这一条错了，芯片上电第一条指令就飞。InRoot$$Sections是 C 库初始化代码的固定段名，漏掉它，全局变量不会被初始化，表现是“变量明明是 5，进 main 变成 0”。.ANY (+RO)是兜底规则，把所有未显式指定的只读内容收进来。

如果某个函数必须固定在某个地址（比如 Bootloader 跳转表），用--keep防止它被链接器当成垃圾回收：

:: 强制保留符号，即使没有任何地方引用 armlink --cpu Cortex-M3 --scatter fw.sct ^ --keep=bl_jump_table ^ --map --info sizes,totals ^ *.o -o fw.axf

--keep后面跟符号名，可以写多次，也可以用--keep=*.o(段名)的形式按段保留。忘了写，函数在 map 文件里找不到，你会在调试器里对着一个空地址发半天呆。

4.4 出包与产物核对

编译链接只是中间步骤，最终交付的是.bin或.hex。fromelf是这一步唯一的工具。

:: 生成裸 bin fromelf --bin --output=fw.bin fw.axf :: 生成 hex，带地址信息 fromelf --i32 --output=fw.hex fw.axf :: 反汇编整个镜像，用于核对关键函数 fromelf --text -c --output=fw.dis fw.axf

--bin只输出纯二进制，不含地址信息，烧录时要自己确认起始偏移。--i32输出 Intel HEX，带地址记录，适合交给产线工具。--text -c生成带 C 源码交织的反汇编，前提是编译时加了-g，否则只有指令没有源码行。

出包后立刻做一次尺寸核对，别等烧进去才发现超了：

findstr /C:"Total RO Size" /C:"Total RW Size" fw.map

这两行数字应该和你对 Flash/RAM 的预期一致。数字对不上，八成是 scatter 写错或者某个大数组被放错了段。

5. 避坑排查：armcc 5.06 在 Windows 上最常翻车的五处

5.1 现象：一启动就报 license 不可用

报错形如C9932E: Cannot obtain license for Compiler，或者armcc进程刚起来就退出，没有任何编译输出。

原因基本是两个：一是这台机器上根本没有可用的授权，MSI 安装包只装工具，不带授权文件；二是环境里残留了指向已下线授权服务器的变量，比如LM_LICENSE_FILE或ARMLMD_LICENSE_FILE指着一个早就关掉的地址，编译器去连、连不上、然后失败。

解决分三步。先清掉当前窗口里的相关变量，看是否恢复：

set LM_LICENSE_FILE= set ARMLMD_LICENSE_FILE= armcc --version

如果清掉就好了，说明是环境变量污染，去系统环境变量里把过期的条目删掉。如果还是不行，确认你手上的授权来自合法渠道（IDE 自带的授权或正规采购的授权），并按授权方式配置。这类工具没有授权就是不能用，绕过的路子既不合规也不稳定，不建议花时间。排查时优先用 IDE 启动编译，因为 IDE 会自己注入正确的授权环境，能快速区分“工具坏了”还是“环境配错了”。

5.2 现象：路径里的中文或空格导致找不到文件

报错是cannot open file或Fatal error: #5: cannot open source input file，但你用资源管理器看文件名明明是对的。

原因是这套 32 位老工具对非 ASCII 路径的处理不稳定，对含空格的路径则需要每一处都正确加引号。命令行里-I./my inc会被拆成两个参数，-I"C:/my inc"才是对的。

解决方式是釜底抽薪：编译器装到C:\tools\ARMCC506，工程目录也用纯英文短路径。已经装了怎么办？做个目录链接，把中文路径映射过去：

:: 把工程链接到纯 ASCII 路径，避免改工程配置 mklink /J C:\work\proj_x D:\项目\某工程

/J是目录联接，对上层工具透明。之后所有 Makefile 和 IDE 配置都指向C:\work\proj_x，问题消失。这个技巧在处理别人交接过来的工程时特别省事。

5.3 现象：链接时报符号重复定义或目标文件不兼容

L6200E: Symbol xxx multiply defined或者Fatal error: L6002U: Could not open file ...\.o。

真正的原因往往不是重复定义，而是build目录里同时躺着 AC5 和 AC6 编出来的.o。两种编译器的目标文件都叫.o，扩展名一样，文件名一样，链接器拿到手才发现属性对不上，报出来的错却指向符号。

解决只有一条：全量重编。

:: 彻底清理，别用增量编译赌运气 del /q /s *.o *.axf *.map *.bin 2>nul

清完再编一次。如果换了编译器版本，连 IDE 的Objects输出目录也要一起删。这类问题最容易在“我先用新编译器试一下，不行再换回来”的操作之后出现，属于典型的自己给自己挖坑。

5.4 现象：版本号对不上，编译行为诡异

明明装的是 5.06，armcc --version出来却是别的版本；或者 IDE 里选的是 5.06，实际编出来的指令集不对。

原因是PATH里有多个armcc.exe，Windows 按顺序取第一个命中的。老机器上装了不止一套工具链时，这个问题几乎必然发生。

先定位所有实例：

where armcc

输出会有多行，第一行就是实际生效的那个。确认它不是你要的，就在脚本里写绝对路径，别依赖PATH：

CC := C:/tools/ARMCC506/bin/armcc.exe

多花一秒钟写死路径，能省掉半天“为什么行为和文档不一样”的困惑。这个习惯我从第一次被PATH坑过之后就再没改过。

5.5 现象：程序一跑就停在 BKPT，或者 printf 没输出

调试器里点运行，程序停在一条BKPT指令上，或者串口一个字节都没出来。

这是半主机（semihosting）机制在起作用：标准库的printf、malloc默认要通过调试器与主机通信，没有调试器接管时就会触发断点。裸机工程必须明确关掉它，并把输出重定向到自己的串口。

在代码里声明不使用半主机，并实现底层写函数：

/* 告诉链接器不要引入半主机相关代码 */ #pragma import(__use_no_semihosting) /* 重定向 fputc 到你自己的串口发送函数 */ int fputc(int ch, FILE *f) { uart_send_byte((uint8_t)ch); return ch; } /* 提供必要的桩函数，避免链接报未定义 */ void _sys_exit(int x) { (void)x; } void _ttywrch(int ch) { (void)ch; }

__use_no_semihosting会让链接器拒绝引入半主机实现，如果还有地方依赖它，链接阶段就会报错，比运行时停在断点好排查得多。fputc是标准库的输出出口，重定向到串口之后printf就能正常出字。这三个桩函数不写全，链接器会报一堆未定义符号，逐个补齐即可。

6. 验证出包可复现：用 map、反汇编和 CRC 把编译结果钉死

“能编译”和“能复现”是两回事。老工程最怕的是：今天出的包和三个月前的包行为不一致，却没人说得清差在哪。我的做法是每次出包都留三样东西——map 文件、反汇编、bin 的 CRC，然后用脚本比对。

先看 map 里的尺寸汇总，这是最粗的一道筛子：

:: 链接时生成 map，并打印尺寸汇总 armlink --cpu Cortex-M3 --scatter fw.sct ^ --map --info sizes,totals ^ *.o -o fw.axf :: 提取关键行 findstr /C:"Total RO Size" /C:"Total RW Size" /C:"Total ROM Size" fw.map

Total RO Size是代码加只读数据，Total RW Size是已初始化变量加零初始化区。这两个数字和上一版差出几百字节，就值得停下来看看是谁变胖了——通常是某个调试打印没关，或者某个数组被误放进了 RAM。

然后是二进制比对。用一段小脚本算 CRC，比人眼看文件大小靠谱：

import sys import zlib from pathlib import Path def crc32_of(path: str) -> int: data = Path(path).read_bytes() return zlib.crc32(data) & 0xFFFFFFFF if __name__ == "__main__": a, b = sys.argv[1], sys.argv[2] ca, cb = crc32_of(a), crc32_of(b) print(f"{a}: 0x{ca:08X}") print(f"{b}: 0x{cb:08X}") print("IDENTICAL" if ca == cb else "DIFFERENT")

用法很直接：python crc_cmp.py old_fw.bin new_fw.bin。两次构建如果源码没动，输出应该是IDENTICAL。

如果显示DIFFERENT而你没改任何代码，八成是__DATE__或__TIME__被写进了固件版本字符串。这两个宏每次编译都变，是破坏可复现构建的头号元凶。解决办法是不要在代码里直接用它们，改成从构建系统传入固定常量：

:: 用构建号替代 __DATE__/__TIME__，保证可复现 armcc -c --cpu Cortex-M3 -O2 ^ -DBUILD_STAMP=\"1.0.7\" ^ main.c -o main.o

源码里用BUILD_STAMP拼版本字符串，构建号由脚本传入，这样同一份源码永远出同一个 bin。

最后一道验证是反汇编抽查。挑两三个关键函数，看它们在新的编译器参数下有没有被意外内联掉：

:: 生成反汇编后检索符号 fromelf --text -c --output=fw.dis fw.axf findstr /C:"delay_good" /C:"bl_jump_table" fw.dis

符号在反汇编里搜不到，说明它被内联或回收了。如果是故意的（比如static小函数），没问题；如果是中断服务函数或跳转表，那就是事故，回去加--keep或者__attribute__((noinline))。

从那以后我每次接手一个老工程，第一件事不是看代码，而是把编译器版本号、build 号、scatter 文件、map 文件和 bin 的 CRC 一起归档到一个目录里，命名带上日期。这个习惯救过我两次——一次是三个月后要回滚，一次是客户说“新固件的某功能不对”，翻出归档一比，CRC 一样，问题在硬件不在软件。希望帮到你。

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