IAR

调试单片机程序时，光盯着变量值看，往往只能弄清楚一部分问题；一旦遇到中断响应不对、外设状态报错、任务切换出现混乱，或者程序干脆跑飞了，还得去翻看CPU内部的寄存器和外设那边的寄存器。要弄明白在IAR C-SPY里怎么查看寄存器发生的变化，以及寄存器窗口的数值一直不刷新可能是什么原因，重点是把普通的一次性查看和程序跑起来以后的持续观察区分开。C-SPY既能查看CPU寄存器、外设寄存器，也能打开内存窗口，并且可以把寄存器分组和调试窗口的布局保存下来，下次再用就方便了许多。

IAR许可证迁移怎么做，先要分清你手上的授权类型。IAR官方公开资料把常见情况分成三类，一类是锁定到当前电脑的PC锁定许可证，一类是跟随加密狗走的移动许可证，另一类是放在许可证服务器上的网络许可证。换电脑后的恢复动作，看起来都像“重新激活”，实际前置步骤并不一样，先把类型分清，后面才不会走错。

很多团队把IAR接进流水线时，最容易卡住的不是编译器本身，而是没有先分清楚本地IDE工程、命令行构建入口和服务器侧工具链这三层。按IAR官方当前口径，IAR Build Tools本身就是面向自动化构建和CI/CD的命令行工具链，支持云端和服务器环境，也支持Linux与Windows；而在传统IAR Embedded Workbench体系里，项目同样可以通过iarbuild.exe从命令行构建，所以真正落地时，关键不是能不能接CI，而是先选好你要用IDE工程驱动，还是用Build Tools做服务器侧统一入口。

做IAR升级，最容易出问题的不是安装程序本身，而是把新版本直接盖到旧环境上，或者装完以后只看工程能不能打开，却没有把许可证、器件支持、编译器变化和调试链路一起核一遍。IAR官方近版发布说明和迁移文档反复强调几件事：新版本不要安装到旧版本目录上，必要时还要同步做许可证续期和License Server Tools升级；如果跨大版本，旧工程还要重点检查IDE、语言选项、库结构和运行时变化。

IAR做STM8调试时，表面现象常常只有一句连不上，但背后原因并不只一种。有时真是驱动和探头链路没起来，有时是【Debugger】里选错了驱动，有时板子没上电、线缆不对，甚至还有一种情况是程序下载阶段写失败，看起来像连不上，实际却是设备型号或链接地址不对。IAR针对STM8的C-SPY调试文档把这条链路拆得很清楚，主机侧通过USB和硬件调试器通信，硬件调试器再通过SWIM和STM8目标芯片通信，IAR安装时也会把STM8相关的C-SPY硬件调试驱动一起装上。

当一颗Flash里面同时存放Bootloader和应用程序时，应用程序就不能再占用上电后默认的中断向量表位置了，否则很容易跟Bootloader的向量表发生冲突。对于支持向量表偏移寄存器（VTOR）的Cortex‑M芯片，正确的做法是把应用程序的向量表整体搬到一个新的起始位置，然后在代码启动过程中更新VTOR，让CPU知道中断入口地址已经变了。如果只调整了链接脚本而漏掉运行时重定位，或者反过来，主函数虽然能跑起来，但定时器、串口和外部中断这类外设往往完全没有反应。Arm的技术文档也说明，软件可以借助VTOR寄存器把向量表重定位到新的内存地址。

写完程序并下载到芯片之后，调试器虽然能连上，但代码并没有按预想的停在main函数的入口，而且单步跟进时还可能突然跳到一些莫名其妙的地址，这种情况在嵌入式开发里头通常就被叫做程序跑飞。排查的时候，可不能光盯着自己写的那些业务代码去看，还要把启动文件、链接脚本里规定的地址、中断向量表、看门狗的设置，还有C-SPY这一头的复位选项，都一并检查。对于Cortex-M这类内核的芯片，向量表里存放了最初的栈顶指针和各个异常处理的入口地址，一旦复位之后程序要去的那个地方搞错了，芯片在刚启动的阶段，就可能直接钻进硬件错误中断，来回不断地复位重启。

很多团队遇到IAR许可证“被占用”时，第一反应都是怀疑有人没退出，或者服务器没释放席位。可从IAR官方许可机制来看，浮动许可本来就不是“用完立刻归还”的模式，而是带有缓存和保留时间；再叠加借用功能后，表面上的“占用”就更容易被误判。IAR官方说明里写得很清楚，网络许可允许产品装在任意数量客户端上，但真正受限的是并发用户数；一次需要许可证的动作结束后，权限还会继续锁在当前客户端30分钟，客户端本地缓存有效期是20分钟，缓存失效后许可证还会继续保留10分钟。

IAR安装后找不到编译器，很多时候并不是编译器真的没装上，而是工程当前指向的目标器件、外部构建设置或安装目录没有对齐。IAR官方文档说明，IDE本身可以同时容纳多个面向不同微控制器的toolchain，编译器、汇编器、链接器也都属于这套build toolchain的一部分；另外，新版EWARM的建议默认安装路径也已经从过去的C盘Program Files变成了C:iar。也就是说，找不到编译器时，先查工程指向，再查安装目录，再查外部构建变量，效率通常最高。

很多人第一次用IAR做板级调试，卡住的往往不是代码本身，而是下载方式、调试驱动和断点入口没有先配顺。按IAR官方的C-SPY调试文档，调试相关设置主要集中在【Project】→【Options】里的【Debugger】分类，里面再分成【Setup】、【Download】等页面；真正开始调试时，则通常从【Project】→【Download and Debug】进入。先把这条主线理顺，后面的下载和断点就不会越点越乱。

在嵌入式工程里，经常得把printf打印的信息送到串口、调试终端或者日志缓存区里去，而不是让它留在控制台上。那么，IAR里面的库函数重定向到底该怎么实现，还有重定向之后打印输出为什么会出问题，这些事的关键，就是先要搞清楚工程用的是哪一个运行库，然后再把底层的输出接口给补上。在IAR的DLIB运行环境下，标准的输入和输出都会被交给一组底层的函数去处理，也就是说，printf和fputc这两个函数，到了最后都会去调用__write这个函数，把字符一个一个地发出去。

在一颗Flash里面同时放进Bootloader、主应用程序、参数区和固件升级区的时候，软件默认的内存划分往往就不够用了。在IAR开发环境底下，经常是通过一个以.icf作为后缀的链接配置文件，来安排代码和数据的存放位置的，ILINK链接器会根据这份文件里对memory、region、block和section placement的定义，把各个段分配到可以使用的内存当中去。调整这个文件的时候，不能只去改一个起始地址，还要把预留的空间、初始化数据块还有栈空间这些因素也一起考虑进来，否则很容易在链接阶段就出问题。

IAR里体感上的“编译慢”，很多时候并不全是编译器本身慢，而是把源码索引、浏览信息更新、无效重建和全量重编都叠在了一起。IAR官方文档把这几层分得很清楚：日常的【Make】本来就是只编译自上次构建后发生变化的文件，而Source Browser又有自己单独的生成、更新和缓存目录；再加上并行构建、构建文件目录和配置隔离，速度差别会非常明显。

很多人刚把IAR和ARM工程接起来时，最容易卡住的不是编译器本身，而是CMSIS、软件包和头文件路径这三件事没有串到一起。表面上看，问题像是找不到`core_cm4.h`、设备头文件不识别，或者换了芯片以后包依赖一片发红；实际上在IAR里，这几步是有固定入口的。IAR当前文档说明，传统CMSIS-Pack工程可以通过【Project】里的【CMSIS-Manager】安装Pack并选择组件，新建工程时还可以直接选择【Empty CMSISPack project】；如果走的是CMake或CMSIS-Toolbox路线，则又有单独的Pack root和自动下载缺包选项。

IAR做ARM开发时，很多人一开始只盯着能不能编过，等到后面出现库不兼容、浮点不对、标准库功能缺口，才发现前面的编译器和运行时其实没选顺。这个问题不好靠补丁式排查解决，更稳的办法是从项目建立那一步就把目标内核、执行模式、语言标准、库配置和底层接口一起对齐。IAR官方文档也把这个逻辑写得很明确，处理顺序不是先挑一个“能编译”的组合，而是先按目标核和工程能力边界去定编译器选项，再让库和运行时跟着这些选项自动匹配。

当程序突然无法写入Flash，或者发现RAM的占用量比上一个版本明显增加的时候，IAR生成的map文件往往比编译窗口里的信息更管用；大家会关心在IAR的map文件里哪些信息最关键，分析的时候又该先去看哪几项占用，正确的做法并不是从头一行行翻看，先把内存区域和汇总结果弄清楚，再回过头去细查模块、段和符号，排查速度就会快上很多。IAR的连接器负责把代码和数据安排到目标内存中，而map文件就是用来查看连接之后各部分摆放情况的一份记录。

工程能够顺利编译通过，并不代表芯片的配置就一定没有问题。要弄清楚IAR工程在选错芯片以后会带来哪些影响，以及芯片器件包切换完之后有哪些设置是需要回头重新检查的，实际得去看目标器件的型号、内核、链接文件、启动代码，还有调试和下载的这些设置，是不是都跟实际用的芯片对得上。在IAR Embedded Workbench里面，目标器件一般是在【Project】→【Options】→【General Options】→【Target】这个地方去选的，这一项选择会直接影响到后面的构建和整个调试环境。

很多团队做IAR交付时，真正麻烦的不是能不能编过，而是发布包里到底该放什么、不同配置怎么一起出、产物名字怎么区分、后面追版本时靠什么回溯。IAR本身已经给了几块很关键的能力，包括Batch Build批量构建、iarbuild.exe命令行构建、Build Actions前后处理、Output Converter输出格式转换，以及把构建信息写入日志文件的能力，所以发布包最好围绕这几项来收口，而不是每次靠人工东拼西凑。

下面按IAR Embedded Workbench for Arm里最常见的Cortex-M工程来写。IAR官方文档明确说明，Cortex-M的中断函数进入和返回方式与普通函数一致，不使用__irq、__fiq这类关键字；同时，异常名和默认向量代码由cstartup_M.c或cstartup_M.s提供。也就是说，IAR里的中断配置，核心不是“给函数加特殊修饰”，而是把启动文件、向量表、链接地址和NVIC设置对齐。

刚接触IAR ARM时，很多人不是不会写代码，而是工程一建起来就开始乱，文件加进去了却编不过，芯片选了却和头文件不一致，启动文件也不知道该用默认的还是自己改一份。IAR官方文档把这条链路拆得很清楚，新工程先从模板或CMSIS-Pack工程创建，再在【Project】→【Options】里确认目标芯片相关参数，最后再决定启动代码是沿用默认运行库实现，还是把修改后的启动文件加入工程。顺序走对了，后面编译和下载会省很多返工时间。