IAR 4.41A 配置 LPC2148 嵌入式工程完整指南

简介：本资源是一份面向嵌入式开发初学者与高校ARM课程实践者的IAR Embedded Workbench for ARM快速入门指南，聚焦NXP LPC2148平台，解决从零搭建工程、编译调试到Flash烧录的全流程实操难题。压缩包为单个806KB的PPT文件，内容结构完整，覆盖创建空工程、添加C/汇编源码、配置编译器优化与头文件路径、设定Linker脚本（LPC2148_flash.xcl等）、选择H-JTAG调试代理及SupperJTAG下载模式等关键环节，并以2007年NXP中国ARM MCU大学设计竞赛为背景，提供可复用的工程模板与典型配置范例。已有512人学习下载，内容兼顾原理说明与界面操作指引，目录层级清晰（含5大模块、11个子项），适合作为课堂讲义、实验预习材料或自学速查手册。

1. 这不是“过时文档”，而是嵌入式老手验证过的 IAR v4.41A 实战切口：LPC2148 工程从零跑通的完整链路

你可能刚点开这个标题就皱眉：“2007 年的手册？现在谁还用 IAR 4.41A？”——我第一次看到它时也这么想。直到在某高校嵌入式实训室里，带学生调试一块停产十年的 LPC2148 开发板，所有新版本 IAR（8.x/9.x）都报 linker 错误、C-SPY 无法识别 H-JTAG 设备、Flash loader 加载失败……最后翻出这本泛黄的 Quick Start Guide，按第 3.7 节选对.xcl链接脚本、第 3.10 节填准H-JTAG.dll路径、第 3.9 节勾选/取消Use flash loader(s)的组合逻辑，5 分钟内跑通 UART 回显。它不是历史文物，而是一把精准匹配 NXP ARM7TDMI + 并口 JTAG 硬件栈的“密钥”。适合三类人：仍在维护工业现场 LPC21xx/LPC22xx 设备的工程师、需要复现经典 ARM7 教学案例的导师、以及想穿透 IAR 工程配置底层逻辑的新手——因为 v4.41A 的选项粒度比新版更裸露，每一步配置背后是什么硬件行为、什么内存映射、什么驱动交互，全写在操作路径里。这不是教你怎么点菜单，而是带你看见菜单背后的寄存器级因果。

2. 创建工程与工具链绑定：ARM v4.41A 的 Empty Project 为什么必须手动指定芯片架构

IAR Embedded Workbench for ARM v4.41A 的工程创建看似简单，但“Empty project”模板的陷阱在于：它不自动关联目标 MCU 的启动代码、向量表布局和外设头文件。你点完Project → Create New Project…后，如果只选Tool chain: ARM而跳过后续关键确认，编译时会直接卡在__vector_table未定义——因为链接器根本不知道该把中断向量塞进 Flash 的 0x00000000 还是 RAM 的 0x40000000。这和现代 IAR（如 9.30+）的 Device Selector 自动注入 startup 文件完全不同。我们必须用最原始的方式把芯片特性“焊死”在工程里。

2.1 创建新工程：从 Start 菜单切入而非桌面快捷方式

提示：务必通过Start → Programs → IAR Systems → IAR Embedded Workbench for ARM → IAR Embedded Workbench启动，而非双击桌面图标。v4.41A 的桌面快捷方式常指向旧版 workspace，导致新建工程后Options对话框中General Options标签页缺失Target子项——这是注册表路径错位的典型症状。若已发生，需手动运行IarIde.exe /reset重置 IDE 配置。

2.2 选择工具链和工程模版：ARM 工具链下的隐含约束

Tool chain: ARM Project templates: Empty project

此处的ARM不是指 ARM Cortex-M，而是特指 ARM7/ARM9 指令集（ARMv4T/ARMv5TE）。v4.41A 尚未支持 Thumb-2，因此当你后续添加.s79汇编文件时，必须确保指令为 ARM 模式（CODE32）或传统 Thumb（CODE16），不能混用IT指令块。若误用 Cortex-M3 的__set_MSP()函数，编译器会静默忽略——因为它根本不认识这个符号，最终导致复位后堆栈溢出。

2.3 保存工程文件：.ewp后缀决定整个配置域

保存为LPC2148_Demo.ewp不仅是命名习惯，更是 IAR 的工程元数据锚点。.ewp文件本质是 XML，记录了：

• ProjectRoot：工程根目录绝对路径（影响后续所有相对路径解析）
• Configuration：默认配置名（如Debug/Release，v4.41A 中此字段不可编辑，硬编码为Debug）
• Template：值为Empty，表示无预置 startup 或 scatter 文件

若你将工程保存在中文路径（如D:\嵌入式\IAR工程\），后续添加文件时Add Files…对话框会因 ANSI 编码问题丢失文件名——这是 v4.41A 的已知缺陷，解决方案只有：强制使用纯英文路径，例如D:\IAR_LPC2148\Demo\。

2.4 工程物理结构初始化：三个必须存在的空目录

在LPC2148_Demo.ewp同级目录下，手动创建以下文件夹：

LPC2148_Demo\ ├── src\ # C/C++ 源文件存放处（.c/.cpp） ├── inc\ # 头文件存放处（.h） └── cfg\ # 链接脚本与配置文件（.xcl/.icf）

原因说明：v4.41A 的Options → C/C++ Compiler → Preprocessor → Additional include directories默认不包含工程根目录，且不支持$PROJ_DIR$宏。若源文件引用#include "lpc2148.h"，而lpc2148.h在inc\下，就必须在Additional include directories中填入..\inc（注意是两个点+反斜杠）。这个路径是相对.ewp文件位置计算的，不是相对当前工作目录。

3. 添加代码与依赖注入：为什么 LPC2148 的启动文件必须从 IAR 自带例程中“抠”出来

v4.41A 的Empty project模板不提供任何启动代码（startup code），这意味着你写的main()永远不会被执行——复位后 CPU 直接跳到 0x00000000，那里是空的。必须手动注入符合 LPC2148 内存映射的向量表和初始化代码。这不是复制粘贴，而是理解 NXP ARM7 的启动流程：上电→读取向量表→执行 Reset Handler→初始化栈指针→调用main()。IAR 自带的LPC2148_flash.xcl和LPC2148_RAM.xcl就是这个流程的二进制契约。

3.1 准备所需文件：从 IAR 安装目录“考古”关键资源

你需要从 IAR 安装路径中提取以下文件（路径基于原文档的Embedded Workbench 4.0）：

• LPC2148_flash.xcl：Flash 启动链接脚本（定义 Flash 起始地址 0x00000000，RAM 起始地址 0x40000000）
• LPC2148_RAM.xcl：RAM 启动链接脚本（定义 RAM 起始地址 0x40000000，所有段均映射到 RAM）
• startup.s79：ARM7 启动汇编文件（含向量表、Reset Handler、Stack Pointer 初始化）

参数说明：LPC2148_flash.xcl中关键段定义：

define symbol __ICFEDIT_region_ROM_start__ = 0x00000000; define symbol __ICFEDIT_region_ROM_end__ = 0x0007FFFF; define symbol __ICFEDIT_region_RAM_start__ = 0x40000000; define symbol __ICFEDIT_region_RAM_end__ = 0x40007FFF;

这些符号被 IAR Linker 读取，生成正确的RO,RW,ZI段布局。若你用新版 ICF 脚本（如LPC2148.icf），其中define memory mem with size = 4G;会导致 linker 报错memory region too large——因为 v4.41A 的 linker 不支持 4G 地址空间声明。

3.2 添加源代码：.s79文件的编码与语法雷区

通过Project → Add Files…添加文件时，注意：

• .c文件：编码必须为 ANSI（非 UTF-8），否则中文注释会导致编译器解析错误
• .s79文件：必须以CODE32开头，且向量表严格按顺序排列：

  CODE32 AREA RESET, DATA, READONLY EXPORT __Vectors __Vectors DCD 0x40000000 ; SP_Init (RAM stack) DCD Reset_Handler ; Reset handler DCD Undef_Handler ; Undefined instruction ; ... 其余向量省略

逻辑说明：DCD 0x40000000是 LPC2148 的 RAM 起始地址，作为初始栈指针（MSP）。若此处填错（如填成0x00000000），复位后 CPU 会尝试向 Flash 写栈，立即触发总线错误（BusFault）并死锁。这就是为什么必须用 IAR 自带例程中的startup.s79——它的地址值经过 NXP 官方验证。

3.3 头文件依赖链：lpc2148.h的宏定义如何影响编译器行为

从 NXP 官方LPC214x User’s Manual获取lpc2148.h后，需检查其关键宏：

#define PLLCFG_Val 0x00000023 // PLL=60MHz, CCLK=60MHz #define MAMCR_Val 0x00000002 // MAM fully enabled

这些宏直接控制SystemInit()函数中寄存器的写入值。若你使用新版lpc2148.h（如来自 Keil MDK），其中PLLCFG_Val可能为0x00000024，会导致 PLL 锁定失败，UART 波特率计算错误——因为PCLK = CCLK / VPBDIV的分频逻辑被破坏。血泪经验：永远以 IAR v4.41A 自带例程中的lpc2148.h为基准，仅修改引脚定义部分。

3.4 汇编与 C 的接口：__main符号的消失之谜

当你添加startup.s79后，编译仍报错Error[Li005]: no definition for "__main"，这是因为 v4.41A 的 C 运行时库（rt7m_le.a）要求__main作为 C 库初始化入口。解决方案是在startup.s79的Reset_Handler末尾添加：

IMPORT __main B __main

原因说明：__main是 IAR C 库的初始化函数，负责.data段复制、.bss段清零、调用全局构造函数。若跳过它，main()中访问的全局变量值是随机内存垃圾。这个细节在新版 IAR 中由--entry参数自动处理，但在 v4.41A 必须手工缝合。

4. 配置工程选项：Linker Command File 与 RDI Driver 的耦合逻辑

v4.41A 的Options对话框是配置核心，但它的标签页设计极易误导人。比如Linker标签页中的Override default program entry point若填入Reset_Handler，反而会导致链接失败——因为__main依赖__vector_table的存在，而__vector_table又依赖.xcl脚本中place in ROM的段声明。真正的配置主干在Linker → Configuration → Linker command file，这里的选择决定了整个内存布局的合法性。

4.1 配置通用选项：Target 设置决定指令集与 ABI

在Options → General Options → Target中：

• Device：必须选Generic ARM device（v4.41A 无 LPC2148 专用设备）
• Endianness：Little endian（LPC2148 硬件强制小端）
• Runtime library：Normal run-time library（非Small，否则printf不可用）

参数说明：Runtime library选择直接影响printf的实现。若选Small，则printf仅支持%d %x，不支持浮点；而Normal版本链接fpl_flt32.o，支持%f，但会增加 4KB 代码体积。这对 512KB Flash 的 LPC2148 是关键权衡。

4.2 选择编译器优化级别：-O2与--no_wrap_dangerous的生死线

在Options → C/C++ Compiler → Optimization中：

• Level：选Medium (-O2)
• 勾选--no_wrap_dangerous（防止有符号整数溢出优化）

原因说明：LPC2148 的外设寄存器操作常涉及位运算，如IO0SET = (1 << 10)。若开启-O3的循环展开，编译器可能将1 << 10优化为常量1024，但若IO0SET是volatile uint32_t*，这种优化是安全的；然而当操作PINSEL0 |= 0x00000001时，-O3可能合并多次写入，导致中间状态丢失。--no_wrap_dangerous确保(int)(a + b)不被优化为a + b，避免 ADC 采样值溢出后符号反转。

4.3 设定头文件包含路径：Additional include directories的路径拼接规则

在Options → C/C++ Compiler → Preprocessor → Additional include directories中填入：

..\inc;..\cfg;C:\Program Files\IAR Systems\Embedded Workbench 4.0\arm\inc

逻辑说明：分号分隔多个路径，IAR 按顺序搜索。..\inc对应工程inc\目录；C:\...\inc是 IAR 自带的标准头文件（如intrinsics.h）。若路径中含空格（如Program Files），必须用英文双引号包裹，否则编译器报错cannot open source file。

4.4 选择输出文件参数：Allow C-SPY-specific extra output file的真实用途

勾选此项后，IAR 会生成.d90文件（debug information），这是 C-SPY 调试器解析符号的唯一依据。若未勾选，下载程序后在 C-SPY 中设置断点会显示No source available——因为调试器找不到main()的地址映射。玄学现象：有时勾选后编译变慢，这是正常的，因为.d90文件需额外解析符号表。

4.5 选择烧写 Flash 的文件格式：simple-code与intel-extended的硬件适配

在Options → Output Converter → Output中：

• Output format：simple-code（用于 IAR 自带 Flash loader）
• File extension：.mot（Motorola S-record）

避坑 / 常见问题 / 排查 / 注意

1. 现象：选择intel-extended后生成.hex，用 Flash Magic 烧写成功，但 IAR 调试时无法停在断点
   原因：.hex文件不含调试信息（.d90），C-SPY 无法关联源码行号
   解决：烧写用.hex，调试用.d90+.mot，二者必须同次编译生成

2. 现象：simple-code格式下载时报错Flash loader initialization failed
   原因：LPC2148_flash.xcl中__ICFEDIT_region_ROM_start__值为0x00000000，但实际 Flash 地址范围是0x00000000-0x0007FFFF，若代码体积超 512KB，loader 会越界
   解决：在Linker → Config → Edit中手动修改region_ROM_end__为0x0007FFFF

3. 现象：Output format选None，编译通过但无法调试
   原因：None表示不生成任何输出文件，C-SPY 失去加载目标
   解决：至少选simple-code或binary

4. 现象：.mot文件在 Flash Magic 中显示Invalid record type
   原因：Output Converter中Record type未选S19（Motorola S19）
   解决：Options → Output Converter → Record type → S19

5. 现象：生成.mot后，C-SPY 下载时提示No valid memory range found
   原因：.mot文件头中地址范围与LPC2148_flash.xcl定义的ROM_start/end不一致
   解决：用文本编辑器打开.mot，检查首行S0记录后的地址是否为00000000

5. 代码下载和调试：H-JTAG + SuperJTAG 的 RDI 驱动链路验证

C-SPY 调试器能否连上目标板，取决于三层驱动的严丝合缝：Windows 系统层的H-JTAG.sys、IAR 应用层的H-JTAG.dll、硬件层的SuperJTAG并口转接头。任何一层错位，都会表现为“连接超时”或“无法识别设备”。这不是网络问题，而是并口时序与 JTAG TAP 控制器的物理握手失败。

5.1 准备调试环境：并口权限与 H-JTAG 服务

在 Windows XP/7 上：

• 以管理员身份运行H-JTAG.exe，点击Install Driver安装H-JTAG.sys
• 运行H-JTAG.exe，在Settings → Port中确认并口地址（如0x378）
• 关闭所有占用并口的程序（如打印机服务、其他 JTAG 工具）

注意：Windows 10/11 默认禁用并口驱动，需在设备管理器中启用“并行端口”并手动更新驱动为H-JTAG.sys。

5.2 下载程序到目标板：Use flash loader(s)的开关哲学

在Options → Debugger → Setup → Driver中：

• Driver：RDI Driver
• Setup：点击Configure→RDI标签页 →DLL path填入H-JTAG.dll绝对路径（如C:\H-JTAG\H-JTAG.dll）

然后在Options → Debugger → Flash Loader中：

• 若调试 RAM：取消勾选Use flash loader(s)，Download to RAM选Yes
• 若调试 Flash：勾选Use flash loader(s)，Loader file选LPC2148_FlashLoader.elf（需从 IAR 安装目录提取）

逻辑说明：Use flash loader(s)开关控制 C-SPY 的下载模式。关闭时，C-SPY 直接通过 JTAG 写 RAM，速度极快；开启时，先下载 Flash loader 到 RAM，再由 loader 执行 Flash 编程算法（擦除/写入/校验），耗时约 30 秒。若开关与.xcl脚本不匹配（如 Flash 模式下未勾选），程序会下载到 RAM 但复位后从 Flash 启动，导致“下载成功却没反应”。

5.3 代码调试：C-SPY 中断点的物理地址映射

设置断点前，必须确认：

• Options → Debugger → Setup → Download中Download选Yes
• Options → Debugger → Setup → Connection中Connection选JTAG

然后：

• 在main()第一行按 F9 设置断点
• 点击Project → Debug（或 F5）
• 若断点显示为空心圆圈（●），表示地址有效；若为实心红点（●），表示已加载

参数说明：C-SPY 断点依赖.d90文件中的__vector_table地址。若LPC2148_flash.xcl中__ICFEDIT_region_ROM_start__为0x00000000，则__vector_table地址为0x00000000，断点才能正确映射。若.xcl错误设为0x00010000，断点会落在非法地址，C-SPY 提示Breakpoint cannot be set at this location。

5.4 退出调试环境：避免 H-JTAG 占用并口导致下次失败

退出调试必须按顺序：

1. 在 C-SPY 窗口中点击Stop Debugging（红色方块按钮）
2. 等待状态栏显示Target disconnected
3. 再关闭 IAR 主窗口

原因说明：若直接关闭 IAR，H-JTAG.dll未释放并口句柄，下次启动时H-JTAG.exe会报错Port already in use。此时需重启电脑或手动结束H-JTAG.exe进程。

6. 验证与进阶：用 UART 回显验证整个工具链的完整性，以及一个让所有新手少走三天的强制习惯

真正验证 IAR v4.41A 工程是否“活”了，不是看编译通过，而是让 LPC2148 的 UART 发出第一声“Hello World”。这需要四层联动全部正确：C 代码中的Uart0_SendString()调用、启动文件中PINSEL0配置为 UART0 功能、链接脚本中__vector_table正确放置、H-JTAG 下载后复位向量跳转无误。任何一个环节断裂，串口就只会沉默。下面是一个最小可验证代码（main.c），它绕过所有外设库，直操作寄存器：

#include "lpc2148.h" // UART0 初始化：PCLK=60MHz, 波特率9600 void UART0_Init(void) { PINSEL0 = 0x00000005; // P0.0=TxD0, P0.1=RxD0 U0LCR = 0x83; // 8位数据, 1停止位, 无校验, DLAB=1 U0DLL = 38; // 60MHz/(16*9600) = 390.625 → DLL=38, DLM=0 U0DLM = 0; U0LCR = 0x03; // DLAB=0, 锁定设置 } // UART0 发送单字节 void UART0_SendByte(uint8_t byte) { while (!(U0LSR & 0x20)); // 等待THR空 U0THR = byte; } // UART0 发送字符串 void UART0_SendString(const char *str) { while (*str) { UART0_SendByte(*str++); } } int main(void) { UART0_Init(); while(1) { UART0_SendString("LPC2148 OK\r\n"); for(volatile int i=0; i<1000000; i++); // 简单延时 } }

关键参数说明：

• PINSEL0 = 0x00000005：将 P0.0/P0.1 功能切换为 UART0，这是 LPC2148 的固定映射，错一位（如0x00000006）就会让 TX 引脚失效
• U0DLL = 38：波特率计算公式为BaudRate = PCLK / (16 * (DLL + DLM * 256))，60MHz/(16*9600)=390.625，取整 DLL=38，误差 0.16%，在 UART 容忍范围内
• while (!(U0LSR & 0x20))：U0LSR的 bit5 是 THR Empty 标志，必须轮询此位，不能用中断——因为中断向量表尚未验证

把这个main.c加入工程，按前述步骤配置.xcl、RDI Driver、Use flash loader(s)，编译下载后，用串口助手（如 XCOM）以 9600 波特率监听，你会看到稳定的LPC2148 OK。那一刻，你就知道：从 2007 年的纸面手册，到此刻屏幕上的字符，整条工具链已经贯通。

从那以后我每次新建 IAR 工程，都强制走一遍这个 UART 验证流程——哪怕只是写个 LED 闪烁，也要先让串口“说话”。因为嵌入式开发里，最贵的不是时间，而是那种“明明代码没错却死活不运行”的焦虑感。而 UART 就是你的“后悔药”，它用最原始的方式告诉你：CPU 在跑、时钟在跳、引脚在输出、工具链在呼吸。希望帮到你。

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