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

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

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

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

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

IAR里最让人头疼的，往往不是报错本身，而是同样一句失败提示，背后可能是编译器、链接器、头文件路径、库文件、链接脚本，甚至版本迁移带来的语言兼容问题。IAR官方文档对这件事的处理思路其实很明确，先在【Build】消息窗口里看清报错层级和来源，再按编译、链接、内存放置、版本差异这几条线往下拆，效率会比一条一条盲改高很多。

刚接手STM8项目的人，最容易把两件事混在一起，一件是工程已经编过了，另一件是程序已经真正下到板子里了。放到IAR里看，STM8下载并不是单独拎一个烧录器窗口去做，而是通过C-SPY调试链路把当前生成的可执行文件送到目标板，常见硬件就是ST-LINK，走的是STM8的SWIM接口。IAR官方文档写得很明确，开始调试会话时就可以直接下载当前程序，ST官方也说明了ST-LINK本身就是面向STM8和STM32的调试与编程工具。

在IAR里把优化开高后，调试窗口里看不到局部变量、Watch里出现Unavailable、变量值跳来跳去，这通常不是调试器坏了，而是编译器为了生成更紧凑或更快的代码，把变量折叠、搬运到寄存器、甚至直接消掉了。想兼顾性能与可调试性，关键在于先弄清楚变量为什么消失，再把调试信息与保留符号的开关按场景配齐。