简介针对Renesas RL78单片机Bootloader与APP协同开发场景这份docx文档专门讲解901子母工程在boot区域与app区域使用同一个中断定时器7的实现并给出boot区域调用app区域函数的过程。内容覆盖中断开启后LED闪烁的使能方式、因子母工程编译时函数名不能相同的命名处理如增加app_前缀以及通过分支表实现地址跳转、应对APP函数大小变化导致入口地址改变的具体方法。资源包仅含1个docx文件容量586KB结构紧凑适合有一定嵌入式基础、正在使用CS开发环境并希望优化Bootloader启动逻辑的开发者阅读。已有1348人学习下载文档结合CS帮助文档的思路整理能为中断复用和跨区域函数调用提供可直接落地的操作参考。1. 一个 RL78 双区项目为何在“共用中断”上翻车做过 Bootloader 的开发者大多碰到过这类问题Boot 区要跑升级协议App 区要跑正常业务两边都用同一个 UART 口收数据那就都得开同一个串口接收中断。某次我在 RL78 上就是这么做的结果 App 一启动CPU 就被 UART 中断占满主循环几乎进不去偶尔收到一帧还带错位一度被当成玄学在调。后来把中断向量入口分流、跳转前外设复位、PIF 标志清理这三件事捋顺问题才算彻底解决。这篇文章就围绕 renesas rl78 单片机 Boot/App 都开启同一个中断这个场景讲清楚 RL78 的向量表为什么不能简单“搬过去”、跳板 ISR 怎么写、跳转前哪些中断残留必须清掉以及优先级、波特率、RAM 共享地址这些参数怎么设。适合正在做 RL78 Bootloader、OTA 双区方案或者已经被“进 App 后中断失灵”折磨过一轮的开发者。后面所有代码都按“两个固件编译时相互不知道对方符号”的前提来写这是双区工程的常态。2. RL78 中断机制与双区跳转向量表重映射为什么不能省2.1 RL78 的向量表是固定的入口只有一个RL78 的中断向量表固定在 code 区低端地址硬件触发中断后会自动从这个区域取入口地址。它的完整路径是外设产生请求、硬件置起 PIF 标志、检查 MK 屏蔽位、对照 ISPR 中断优先级最后跳向向量表里对应的入口。整个过程由 INTC 控制不经过软件干预。这里要特别强调一个常见误解Boot 和 App 各自写了__interrupt函数不代表硬件会自动区分当前该用谁的向量表。RL78 不像某些内核那样有一个寄存器可以把整个向量表重新定位到别处即使部分子系列支持第二向量表功能也需要按具体手册配置并且限制比想象中多。所以双区共用一个中断源时物理上只能有一个中断入口。这个入口必然在 Boot 区因为 0x0000 起始的向量表在 Boot 镜像里。App 自己构建的“向量表”不会被硬件直接使用需要在 Boot 的入口处做一次转发。2.2 入口分流跳板 ISR 运行状态标志我常用的做法是保留 Boot 的向量入口在它里面加一层很薄的跳板。全局维护一个运行状态字记录“当前是 Boot 在工作还是已经跳进 App”。中断进来时跳板读这个状态字按身份把执行权转交出去。跳板要做的事情越少越好。不要在这里读串口数据不要做协议解析更不要调用耗时的 printf。原因有两点一是跳板本身是在中断上下文里耗时越长越容易丢下一次触发二是如果 Boot 把数据寄存器读了App 的 ISR 再读就什么都拿不到会出现“第一帧总丢”的怪毛病。App 那边要做的是把自己的 ISR 地址在启动早期写到 Boot 和 App 约定好的 RAM 地址槽里。这样 Boot 跳板拿到的是一个具体的函数地址而不是一个符号名。两个工程各自独立编译靠这个 RAM 地址槽完成“握手”。2.3 外设复位和 PIF 清理为什么必须跟着跳转走真正让大多数人在这个标题上翻车的不是向量入口而是跳转前没有处理中断残留。RL78 的串口收到一个字节时硬件会置起对应的 PIF 位如果此时在 Boot 里已经开了 UART 中断跳转时空口没有复位PIF 位依然挂着甚至中断屏蔽位 MK 还开着。跳进 App 后App 初始化串口、打开中断屏蔽挂着的 PIF 位立刻又变成一次新的中断请求。于是 App 进不了主循环永远停在 ISR 里。表现上就是“CPU 被打满”、“主循环跑不动”、“程序像死了一样”。处理办法是跳转前做三件事用外设复位寄存器把 UART 模块复位到默认态、清掉对应 PIF 位、暂时屏蔽相关中断。这三个操作顺序固定漏一个都容易出现“偶尔好、偶尔坏”的隐性故障。3. 让 Boot 与 App 各自处理同一个中断跳板转发与跳转的最小实现3.1 Boot 侧中断跳板与跳转函数下面这段代码是 Boot 工程里的两个核心函数一个是 UART0 接收中断的跳板一个是跳向 App 的跳转函数。/* boot_isr.c —— Boot 工程 */ #define BOOT_STATE_BOOT 0x5A5A #define BOOT_STATE_APP 0xA5A5 volatile uint16_t g_boot_state BOOT_STATE_BOOT; volatile uint32_t g_app_uart0_rx_isr 0UL; void Boot_UART0_RX_ISR(void) __interrupt(INTU0R) { /* 跳板层只分流不读数据不做协议处理 */ if (g_boot_state BOOT_STATE_APP g_app_uart0_rx_isr ! 0UL) { /* 清掉挂起的PIF位再把执行权交给App的ISR */ PIF0L ~0x08U; ((void (*)(void))g_app_uart0_rx_isr)(); return; } /* 处于Boot阶段走升级协议自己的收包逻辑 */ Boot_Rx_Process(); } void Boot_Jump_To_App(void) { /* 1. 关全局中断防止跳转过程被中途打断 */ DI(); /* 2. 复位UART0模块具体掩码以目标子系列手册为准 */ PRR0 | 0x01U; /* 3. 清挂起的中断请求标志 */ PIF0L 0x00U; /* 4. 暂时屏蔽全部可屏蔽中断 */ MK0L 0xFFU; /* 5. 记录运行状态让下次中断走App侧 */ g_boot_state BOOT_STATE_APP; /* 6. 跳到App入口入口地址由App链接脚本固定 */ typedef void (*EntryFunc)(void); EntryFunc entry (EntryFunc)APP_ENTRY_ADDR; entry(); }跳板函数里的逻辑说明先判断运行状态和 App 是否已经注册好 ISR 地址二者都满足才转发。特意不读RXD0是为了把数据完整留给 App 的 ISR。清 PIF 是为了防止 Boot 跳板返回后触发第二次中断。跳转函数里最值得关注的是顺序先关中断再复位外设然后清标志最后改状态并跳转。PRR0的掩码必须按你实际使用的 RL78 子系列手册来写有的系列 UART0 不对应 bit0照抄会适得其反。App 入口地址同样要和你 App 工程的链接脚本严格一致。3.2 App 侧注册 ISR 地址并接管串口App 工程在启动后要立刻把 ISR 地址写到约定槽位然后重新初始化串口打开自己的中断。/* app_main.c —— App 工程 */ extern volatile uint32_t g_app_uart0_rx_isr; void App_UART0_RX_ISR(void) __interrupt(INTU0R) { uint8_t ch; /* 从数据寄存器取字节进入App自己的接收状态机 */ ch RXD0; App_RX_StateMachine(ch); } void App_Start(void) { /* 第一步把自己的ISR地址写进共享RAM槽 */ g_app_uart0_rx_isr (uint32_t)App_UART0_RX_ISR; /* 第二步复位UART0重新初始化外设 */ PRR0 ~0x01U; /* 第三步配置串口参数然后清一次PIF并打开中断 */ PIF0L ~0x08U; MK0L ~0x08U; EI(); }这段代码的逻辑重点在于“先注册再初始化”。如果先初始化外设再注册地址中间一旦来一个字节跳板会发现 ISR 地址还是 0直接走 Boot 协议处理把正常业务帧当成升级帧解析状态机就乱了。串口具体参数波特率、停止位、校验位和 RL78 的 SMR、SDR、STM 寄存器配置有关不同子系列差异很大这里不展开按你手上的用户手册初始化即可。有一点要提醒App 的__interrupt写法在 IAR 下是这样在瑞萨 CC-RL 下可能是#pragma interrupt语法移植时注意工具链差异。3.3 两个固件之间要约定哪些地址共享 RAM 槽和 App 入口地址不能靠猜必须在两个工程的链接脚本里固定下来。我习惯用下面这张表做设计约定约定项示例值说明App 入口地址0x10000Boot 直接跳到这里App 启动代码负责初始化栈和 RAM运行状态字 g_boot_state0xFED00Boot 与 App 都能访问的绝对 RAM 地址ISR 地址槽 g_app_uart0_rx_isr0xFED04App 启动后写入自己的 ISR 地址如果你的工具链支持#pragma address这类扩展语法可以直接把变量指定到绝对地址。不支持就用链接脚本划段总之两个工程要按同一份布局图生产固件否则 Boot 读到的地址可能是 App 里的其他变量跳板就会飞到意想不到的地方。这里还有一个很多人忽略的坑App 的启动代码通常会做 RAM 初始化如果共享状态字被归到了普通 RAM 段App 上电后可能把 Boot 写入的状态字清零。所以共享变量要么放在不清零的保留段要么在 App 启动时主动重新设置一遍后面避坑章节会专门说。4. 三个必调参数中断优先级、PIF 清理时机与共享地址布局4.1 中断优先级ISPR升级中断不能被业务中断饿死RL78 的每个中断都有对应的优先级设置位写在 ISPR 寄存器的相关位里。优先级设置有讲究Boot 升级阶段UART 接收中断必须配到最高因为升级包是一帧一帧来的中间被其他中断拖太久串口 FIFO 又浅很容易丢字节。App 阶段则按业务需要重新分配优先级。常见错误是把 Boot 和 App 用同一套 ISPR 配置但两边对实时性的要求可能完全不同。比如 Boot 升级协议要求 UART 优先App 可能要求定时器优先。跳转函数里把 ISPR 的配置工作留给 App 自己Boot 只负责清掉旧的优先级设置让 App 初始化时按自己的节奏写。我一般在 Boot 的升级入口做一次统一设置把 UART0 对应的 ISPR 位设为最高同时把无关外设的中断屏蔽掉。下载完成要跳转前复位 ISPR 到默认值。这样即使 App 初始化代码有遗漏也不会继承 Boot 的“升级专用优先级”。4.2 PIF 清理时机跳转前清一次App 启动后再清一次PIF 位是被硬件置起的软件可以写清除。最安全的做法是清两次第一次在 Boot 跳转前配合外设复位一起做第二次在 App 外设初始化之后、开中断之前做。第一次清的是跳转瞬间还挂在寄存器里的残留请求第二次清的是 App 初始化串口过程中新产生的不需要的标志。有人觉得清一次就够了我在实际项目中遇到过清一次不够的情况。原因是 Boot 跳板里已经进入过中断从中断返回本来就会清一部分标志但串口外设如果还活着只要 RXD 线上有电平变动新的 PIF 会再次置起。App 初始化串口时模块从复位到使能的过程中也可能产生一次虚假请求。所以跳转前做外设复位和清 PIF 是第一步App 初始化后再补一次才算是把中断风暴的可能性彻底压死。注意写 PIF 清位时尽量只动当前中断对应的位不要整字节清零避免误清其他中断源。4.3 共享 RAM 地址槽必须避开 App 的初始化清零区共享 RAM 是双区中断方案里最容易出玄学问题的地方。Boot 在跳转前把状态字写成BOOT_STATE_APP结果 App 启动代码执行一段 RAM 清零这段地址恰好被覆盖跳板再判断状态时就回到了 Boot 分支。解决方式有三种按踩坑概率从低到高排序第一种是把共享变量放到具有“不清零”属性的保留段工具链一般都有这类扩展语法第二种是在 App 启动后第一时间重新写状态字和 ISR 地址趁初始化代码还没跑完之前完成第三种是给状态字加 magic 校验比如值必须同时满足高 16 位是0xA5A5、低 16 位是0xA5A5才算有效降低数据恰好撞对的概率。第三种在调试时特别有用。RAM 被初始化后内容是随机的恰好等于0x5A5A的概率存在但并不高用 32 位 magic 后几乎可以忽略误判。实际项目中我把状态字扩展成了 32 位效果比原来 16 位稳定得多。5. 避坑跳转后“中断失灵”的五个真实场景与现场排查5.1 跳进 App 后中断风暴主循环进不去现象App 能运行但 CPU 一直在中断里出不来主循环的 LED 翻转明显变慢用调试器打断程序停在 ISR 里。原因跳转前没有复位 UART 外设PIF 位还挂着App 开中断后立刻重入或者跳转函数里没有先DI()跳转过程中串口刚好来数据中断把跳转流程打断。解决跳转前严格按“DI → 外设复位 → 清 PIF → 屏蔽中断 → 跳转”的顺序执行。补全之后再测中断风暴基本消失。如果还复现可以把 App 初始化里的串口配置和 Boot 跳板里的配置逐行对比看看是不是波特率寄存器残留导致超时帧。5.2 App 串口第一帧数据总是丢现象App 运行后上位机发的第一包数据收不到第二包开始正常。每次重新上电复现不是偶发。原因第一帧到达时Boot 跳板已经触发了中断但跳板里不小心读了数据寄存器或者把 PIF 清得太早。App 的 ISR 再执行时只能拿到空寄存器状态机收不齐这一帧。解决跳板 ISR 里只做状态判断和函数跳转任何读取 RXD 的操作都不要写。串口数据到达后只要不被读走硬件寄存器会一直保存到 App ISR 执行。把读数据的动作完全留给 App这个问题就能解决。5.3 想直接改 Boot 向量表结果升级中断失效现象有人为了让 App 的 ISR 生效在 Boot 运行中直接改写向量表所在 Flash 区域然后整个程序跑飞连升级也进不去了。原因Boot 的向量表和 Boot 代码往往在同一个物理 Flash 扇区Boot 正从这片区域取指令执行时自改写 Flash 的操作会打断取指甚至擦除后中断入口直接丢失。解决不要在运行时改写自己的 Flash 向量表。中断转发统一走 RAM 里的地址槽和状态判断向量表保持出厂原样。如果确实需要动态多路转发也要先把相关代码复制到 RAM 中执行再操作 Flash不过这个复杂度在这里没必要。5.4 共享状态字被 App 启动代码清零现象Boot 跳转正常App 串口也初始化了但第一个中断进来后跳板还是走了 Boot 的协议分支业务帧被当成升级帧。原因共享变量被放在普通 RAM 段App 的启动代码做 RAM 初始化时把它清零或者踩到了其他初始化逻辑。解决把g_boot_state和g_app_uart0_rx_isr放进保留段或者用工具链提供的绝对地址定位语法固定到不参与 RAM 清零的区域。我自己的习惯是给状态字加 32 位 magic并让 App 在 main 开头重新写一次状态字双保险。5.5 升级时握手包偶尔收不到现象进入 Boot 后上位机连续发同步头Boot 偶尔能收到、偶尔收不到抓波形看不出规律。原因Boot 侧中断优先级没配好或者上电后旧的 PIF 位没清。RL78 上电后各外设的复位状态不是完全统一的如果 Boot 入口处直接打开中断某个悬空的引脚电平会触发一个虚假中断请求抢占接收中断。解决Boot 的初始化代码里在最开头把所有用到的外设复位一遍并清 PIF、屏蔽中断再进入协议监听。升级窗口内把 UART 中断优先级提到最高其余外设能关就关。这套组合拳打下来握手包丢失基本不会再出现。6. 进阶验证技巧把“中断转发”画出来看再收敛成跳板表6.1 用 GPIO 脉冲测 ISR 执行时序中断类问题最怕“偶尔出现、规律难寻”。我调试共用中断时一定会借助 GPIO 拉高拉低把 ISR 的进出时间画出来。方法很简单在 Boot 跳板入口处拉高一个测试引脚调用完 App ISR 后再拉低。用逻辑分析仪的通道夹住这个引脚和串口 RX就可以直观看到每次数据到达后中断从进入到退出耗时多少有没有连续脉冲。/* 在Boot跳板里加两行仅调试用 */ void Boot_UART0_RX_ISR(void) { P1 | 0x01U; /* 进入跳板拉高 */ if (g_boot_state BOOT_STATE_APP) { PIF0L ~0x08U; ((void (*)(void))g_app_uart0_rx_isr)(); } else { Boot_Rx_Process(); } P1 ~0x01U; /* 退出跳板拉低 */ }如果示波器上看到一次 RX 下降沿对应两个脉冲说明发生了中断重入如果脉冲宽度异常宽说明 ISR 里出现了阻塞操作。这两个现象都能直接定位到具体代码比靠猜高效太多。6.2 收敛成一张可扩展的中断跳板表共用中断的场景一旦多起来比如 UART0 接收、UART0 错误、定时器通道共用逐一手写跳板就会变成流水账。我一般会把它统一成一张“中断跳板表”由 App 在启动时一次性注册typedef struct { uint16_t magic; /* 固定为0x5AA5用于校验有效性 */ uint8_t version; /* 布局版本号 */ uint8_t isr_num; /* 表项数量 */ uint32_t isr_addr[8]; /* 每项对应一个中断源的App处理地址 */ } App_IntVectTable;Boot 侧只认这张表的起始地址中断进来后按中断源索引查表。以后 App 想增加一个共用中断只需要改 App 自己的数组定义Boot 代码几乎不用动。这个做法配合跳板 ISR可以让双区中断转发的代码从“每次都要动两个工程”变成“只改 App 一侧”后期维护成本低很多。回顾这个标题相关的经历我最深的教训是RL78 这类 MCU 在双区中断上并没有太多“高级技巧”关键全在跳转前处理干净。外设复位、PIF 清理、状态字写入、地址槽注册每一步都是笨功夫但少一步就会在 App 运行几十分钟后以难以复现的方式回报你。希望这篇文章能让你少走一圈我当时走过的弯路也希望那个 GPIO 测脉冲的办法能帮你把下一次中断问题从玄学变成看得见的波形希望帮到你。本文还有配套的精品资源点击获取
简介针对Renesas RL78单片机Bootloader与APP协同开发场景这份docx文档专门讲解901子母工程在boot区域与app区域使用同一个中断定时器7的实现并给出boot区域调用app区域函数的过程。内容覆盖中断开启后LED闪烁的使能方式、因子母工程编译时函数名不能相同的命名处理如增加app_前缀以及通过分支表实现地址跳转、应对APP函数大小变化导致入口地址改变的具体方法。资源包仅含1个docx文件容量586KB结构紧凑适合有一定嵌入式基础、正在使用CS开发环境并希望优化Bootloader启动逻辑的开发者阅读。已有1348人学习下载文档结合CS帮助文档的思路整理能为中断复用和跨区域函数调用提供可直接落地的操作参考。1. 一个 RL78 双区项目为何在“共用中断”上翻车做过 Bootloader 的开发者大多碰到过这类问题Boot 区要跑升级协议App 区要跑正常业务两边都用同一个 UART 口收数据那就都得开同一个串口接收中断。某次我在 RL78 上就是这么做的结果 App 一启动CPU 就被 UART 中断占满主循环几乎进不去偶尔收到一帧还带错位一度被当成玄学在调。后来把中断向量入口分流、跳转前外设复位、PIF 标志清理这三件事捋顺问题才算彻底解决。这篇文章就围绕 renesas rl78 单片机 Boot/App 都开启同一个中断这个场景讲清楚 RL78 的向量表为什么不能简单“搬过去”、跳板 ISR 怎么写、跳转前哪些中断残留必须清掉以及优先级、波特率、RAM 共享地址这些参数怎么设。适合正在做 RL78 Bootloader、OTA 双区方案或者已经被“进 App 后中断失灵”折磨过一轮的开发者。后面所有代码都按“两个固件编译时相互不知道对方符号”的前提来写这是双区工程的常态。2. RL78 中断机制与双区跳转向量表重映射为什么不能省2.1 RL78 的向量表是固定的入口只有一个RL78 的中断向量表固定在 code 区低端地址硬件触发中断后会自动从这个区域取入口地址。它的完整路径是外设产生请求、硬件置起 PIF 标志、检查 MK 屏蔽位、对照 ISPR 中断优先级最后跳向向量表里对应的入口。整个过程由 INTC 控制不经过软件干预。这里要特别强调一个常见误解Boot 和 App 各自写了__interrupt函数不代表硬件会自动区分当前该用谁的向量表。RL78 不像某些内核那样有一个寄存器可以把整个向量表重新定位到别处即使部分子系列支持第二向量表功能也需要按具体手册配置并且限制比想象中多。所以双区共用一个中断源时物理上只能有一个中断入口。这个入口必然在 Boot 区因为 0x0000 起始的向量表在 Boot 镜像里。App 自己构建的“向量表”不会被硬件直接使用需要在 Boot 的入口处做一次转发。2.2 入口分流跳板 ISR 运行状态标志我常用的做法是保留 Boot 的向量入口在它里面加一层很薄的跳板。全局维护一个运行状态字记录“当前是 Boot 在工作还是已经跳进 App”。中断进来时跳板读这个状态字按身份把执行权转交出去。跳板要做的事情越少越好。不要在这里读串口数据不要做协议解析更不要调用耗时的 printf。原因有两点一是跳板本身是在中断上下文里耗时越长越容易丢下一次触发二是如果 Boot 把数据寄存器读了App 的 ISR 再读就什么都拿不到会出现“第一帧总丢”的怪毛病。App 那边要做的是把自己的 ISR 地址在启动早期写到 Boot 和 App 约定好的 RAM 地址槽里。这样 Boot 跳板拿到的是一个具体的函数地址而不是一个符号名。两个工程各自独立编译靠这个 RAM 地址槽完成“握手”。2.3 外设复位和 PIF 清理为什么必须跟着跳转走真正让大多数人在这个标题上翻车的不是向量入口而是跳转前没有处理中断残留。RL78 的串口收到一个字节时硬件会置起对应的 PIF 位如果此时在 Boot 里已经开了 UART 中断跳转时空口没有复位PIF 位依然挂着甚至中断屏蔽位 MK 还开着。跳进 App 后App 初始化串口、打开中断屏蔽挂着的 PIF 位立刻又变成一次新的中断请求。于是 App 进不了主循环永远停在 ISR 里。表现上就是“CPU 被打满”、“主循环跑不动”、“程序像死了一样”。处理办法是跳转前做三件事用外设复位寄存器把 UART 模块复位到默认态、清掉对应 PIF 位、暂时屏蔽相关中断。这三个操作顺序固定漏一个都容易出现“偶尔好、偶尔坏”的隐性故障。3. 让 Boot 与 App 各自处理同一个中断跳板转发与跳转的最小实现3.1 Boot 侧中断跳板与跳转函数下面这段代码是 Boot 工程里的两个核心函数一个是 UART0 接收中断的跳板一个是跳向 App 的跳转函数。/* boot_isr.c —— Boot 工程 */ #define BOOT_STATE_BOOT 0x5A5A #define BOOT_STATE_APP 0xA5A5 volatile uint16_t g_boot_state BOOT_STATE_BOOT; volatile uint32_t g_app_uart0_rx_isr 0UL; void Boot_UART0_RX_ISR(void) __interrupt(INTU0R) { /* 跳板层只分流不读数据不做协议处理 */ if (g_boot_state BOOT_STATE_APP g_app_uart0_rx_isr ! 0UL) { /* 清掉挂起的PIF位再把执行权交给App的ISR */ PIF0L ~0x08U; ((void (*)(void))g_app_uart0_rx_isr)(); return; } /* 处于Boot阶段走升级协议自己的收包逻辑 */ Boot_Rx_Process(); } void Boot_Jump_To_App(void) { /* 1. 关全局中断防止跳转过程被中途打断 */ DI(); /* 2. 复位UART0模块具体掩码以目标子系列手册为准 */ PRR0 | 0x01U; /* 3. 清挂起的中断请求标志 */ PIF0L 0x00U; /* 4. 暂时屏蔽全部可屏蔽中断 */ MK0L 0xFFU; /* 5. 记录运行状态让下次中断走App侧 */ g_boot_state BOOT_STATE_APP; /* 6. 跳到App入口入口地址由App链接脚本固定 */ typedef void (*EntryFunc)(void); EntryFunc entry (EntryFunc)APP_ENTRY_ADDR; entry(); }跳板函数里的逻辑说明先判断运行状态和 App 是否已经注册好 ISR 地址二者都满足才转发。特意不读RXD0是为了把数据完整留给 App 的 ISR。清 PIF 是为了防止 Boot 跳板返回后触发第二次中断。跳转函数里最值得关注的是顺序先关中断再复位外设然后清标志最后改状态并跳转。PRR0的掩码必须按你实际使用的 RL78 子系列手册来写有的系列 UART0 不对应 bit0照抄会适得其反。App 入口地址同样要和你 App 工程的链接脚本严格一致。3.2 App 侧注册 ISR 地址并接管串口App 工程在启动后要立刻把 ISR 地址写到约定槽位然后重新初始化串口打开自己的中断。/* app_main.c —— App 工程 */ extern volatile uint32_t g_app_uart0_rx_isr; void App_UART0_RX_ISR(void) __interrupt(INTU0R) { uint8_t ch; /* 从数据寄存器取字节进入App自己的接收状态机 */ ch RXD0; App_RX_StateMachine(ch); } void App_Start(void) { /* 第一步把自己的ISR地址写进共享RAM槽 */ g_app_uart0_rx_isr (uint32_t)App_UART0_RX_ISR; /* 第二步复位UART0重新初始化外设 */ PRR0 ~0x01U; /* 第三步配置串口参数然后清一次PIF并打开中断 */ PIF0L ~0x08U; MK0L ~0x08U; EI(); }这段代码的逻辑重点在于“先注册再初始化”。如果先初始化外设再注册地址中间一旦来一个字节跳板会发现 ISR 地址还是 0直接走 Boot 协议处理把正常业务帧当成升级帧解析状态机就乱了。串口具体参数波特率、停止位、校验位和 RL78 的 SMR、SDR、STM 寄存器配置有关不同子系列差异很大这里不展开按你手上的用户手册初始化即可。有一点要提醒App 的__interrupt写法在 IAR 下是这样在瑞萨 CC-RL 下可能是#pragma interrupt语法移植时注意工具链差异。3.3 两个固件之间要约定哪些地址共享 RAM 槽和 App 入口地址不能靠猜必须在两个工程的链接脚本里固定下来。我习惯用下面这张表做设计约定约定项示例值说明App 入口地址0x10000Boot 直接跳到这里App 启动代码负责初始化栈和 RAM运行状态字 g_boot_state0xFED00Boot 与 App 都能访问的绝对 RAM 地址ISR 地址槽 g_app_uart0_rx_isr0xFED04App 启动后写入自己的 ISR 地址如果你的工具链支持#pragma address这类扩展语法可以直接把变量指定到绝对地址。不支持就用链接脚本划段总之两个工程要按同一份布局图生产固件否则 Boot 读到的地址可能是 App 里的其他变量跳板就会飞到意想不到的地方。这里还有一个很多人忽略的坑App 的启动代码通常会做 RAM 初始化如果共享状态字被归到了普通 RAM 段App 上电后可能把 Boot 写入的状态字清零。所以共享变量要么放在不清零的保留段要么在 App 启动时主动重新设置一遍后面避坑章节会专门说。4. 三个必调参数中断优先级、PIF 清理时机与共享地址布局4.1 中断优先级ISPR升级中断不能被业务中断饿死RL78 的每个中断都有对应的优先级设置位写在 ISPR 寄存器的相关位里。优先级设置有讲究Boot 升级阶段UART 接收中断必须配到最高因为升级包是一帧一帧来的中间被其他中断拖太久串口 FIFO 又浅很容易丢字节。App 阶段则按业务需要重新分配优先级。常见错误是把 Boot 和 App 用同一套 ISPR 配置但两边对实时性的要求可能完全不同。比如 Boot 升级协议要求 UART 优先App 可能要求定时器优先。跳转函数里把 ISPR 的配置工作留给 App 自己Boot 只负责清掉旧的优先级设置让 App 初始化时按自己的节奏写。我一般在 Boot 的升级入口做一次统一设置把 UART0 对应的 ISPR 位设为最高同时把无关外设的中断屏蔽掉。下载完成要跳转前复位 ISPR 到默认值。这样即使 App 初始化代码有遗漏也不会继承 Boot 的“升级专用优先级”。4.2 PIF 清理时机跳转前清一次App 启动后再清一次PIF 位是被硬件置起的软件可以写清除。最安全的做法是清两次第一次在 Boot 跳转前配合外设复位一起做第二次在 App 外设初始化之后、开中断之前做。第一次清的是跳转瞬间还挂在寄存器里的残留请求第二次清的是 App 初始化串口过程中新产生的不需要的标志。有人觉得清一次就够了我在实际项目中遇到过清一次不够的情况。原因是 Boot 跳板里已经进入过中断从中断返回本来就会清一部分标志但串口外设如果还活着只要 RXD 线上有电平变动新的 PIF 会再次置起。App 初始化串口时模块从复位到使能的过程中也可能产生一次虚假请求。所以跳转前做外设复位和清 PIF 是第一步App 初始化后再补一次才算是把中断风暴的可能性彻底压死。注意写 PIF 清位时尽量只动当前中断对应的位不要整字节清零避免误清其他中断源。4.3 共享 RAM 地址槽必须避开 App 的初始化清零区共享 RAM 是双区中断方案里最容易出玄学问题的地方。Boot 在跳转前把状态字写成BOOT_STATE_APP结果 App 启动代码执行一段 RAM 清零这段地址恰好被覆盖跳板再判断状态时就回到了 Boot 分支。解决方式有三种按踩坑概率从低到高排序第一种是把共享变量放到具有“不清零”属性的保留段工具链一般都有这类扩展语法第二种是在 App 启动后第一时间重新写状态字和 ISR 地址趁初始化代码还没跑完之前完成第三种是给状态字加 magic 校验比如值必须同时满足高 16 位是0xA5A5、低 16 位是0xA5A5才算有效降低数据恰好撞对的概率。第三种在调试时特别有用。RAM 被初始化后内容是随机的恰好等于0x5A5A的概率存在但并不高用 32 位 magic 后几乎可以忽略误判。实际项目中我把状态字扩展成了 32 位效果比原来 16 位稳定得多。5. 避坑跳转后“中断失灵”的五个真实场景与现场排查5.1 跳进 App 后中断风暴主循环进不去现象App 能运行但 CPU 一直在中断里出不来主循环的 LED 翻转明显变慢用调试器打断程序停在 ISR 里。原因跳转前没有复位 UART 外设PIF 位还挂着App 开中断后立刻重入或者跳转函数里没有先DI()跳转过程中串口刚好来数据中断把跳转流程打断。解决跳转前严格按“DI → 外设复位 → 清 PIF → 屏蔽中断 → 跳转”的顺序执行。补全之后再测中断风暴基本消失。如果还复现可以把 App 初始化里的串口配置和 Boot 跳板里的配置逐行对比看看是不是波特率寄存器残留导致超时帧。5.2 App 串口第一帧数据总是丢现象App 运行后上位机发的第一包数据收不到第二包开始正常。每次重新上电复现不是偶发。原因第一帧到达时Boot 跳板已经触发了中断但跳板里不小心读了数据寄存器或者把 PIF 清得太早。App 的 ISR 再执行时只能拿到空寄存器状态机收不齐这一帧。解决跳板 ISR 里只做状态判断和函数跳转任何读取 RXD 的操作都不要写。串口数据到达后只要不被读走硬件寄存器会一直保存到 App ISR 执行。把读数据的动作完全留给 App这个问题就能解决。5.3 想直接改 Boot 向量表结果升级中断失效现象有人为了让 App 的 ISR 生效在 Boot 运行中直接改写向量表所在 Flash 区域然后整个程序跑飞连升级也进不去了。原因Boot 的向量表和 Boot 代码往往在同一个物理 Flash 扇区Boot 正从这片区域取指令执行时自改写 Flash 的操作会打断取指甚至擦除后中断入口直接丢失。解决不要在运行时改写自己的 Flash 向量表。中断转发统一走 RAM 里的地址槽和状态判断向量表保持出厂原样。如果确实需要动态多路转发也要先把相关代码复制到 RAM 中执行再操作 Flash不过这个复杂度在这里没必要。5.4 共享状态字被 App 启动代码清零现象Boot 跳转正常App 串口也初始化了但第一个中断进来后跳板还是走了 Boot 的协议分支业务帧被当成升级帧。原因共享变量被放在普通 RAM 段App 的启动代码做 RAM 初始化时把它清零或者踩到了其他初始化逻辑。解决把g_boot_state和g_app_uart0_rx_isr放进保留段或者用工具链提供的绝对地址定位语法固定到不参与 RAM 清零的区域。我自己的习惯是给状态字加 32 位 magic并让 App 在 main 开头重新写一次状态字双保险。5.5 升级时握手包偶尔收不到现象进入 Boot 后上位机连续发同步头Boot 偶尔能收到、偶尔收不到抓波形看不出规律。原因Boot 侧中断优先级没配好或者上电后旧的 PIF 位没清。RL78 上电后各外设的复位状态不是完全统一的如果 Boot 入口处直接打开中断某个悬空的引脚电平会触发一个虚假中断请求抢占接收中断。解决Boot 的初始化代码里在最开头把所有用到的外设复位一遍并清 PIF、屏蔽中断再进入协议监听。升级窗口内把 UART 中断优先级提到最高其余外设能关就关。这套组合拳打下来握手包丢失基本不会再出现。6. 进阶验证技巧把“中断转发”画出来看再收敛成跳板表6.1 用 GPIO 脉冲测 ISR 执行时序中断类问题最怕“偶尔出现、规律难寻”。我调试共用中断时一定会借助 GPIO 拉高拉低把 ISR 的进出时间画出来。方法很简单在 Boot 跳板入口处拉高一个测试引脚调用完 App ISR 后再拉低。用逻辑分析仪的通道夹住这个引脚和串口 RX就可以直观看到每次数据到达后中断从进入到退出耗时多少有没有连续脉冲。/* 在Boot跳板里加两行仅调试用 */ void Boot_UART0_RX_ISR(void) { P1 | 0x01U; /* 进入跳板拉高 */ if (g_boot_state BOOT_STATE_APP) { PIF0L ~0x08U; ((void (*)(void))g_app_uart0_rx_isr)(); } else { Boot_Rx_Process(); } P1 ~0x01U; /* 退出跳板拉低 */ }如果示波器上看到一次 RX 下降沿对应两个脉冲说明发生了中断重入如果脉冲宽度异常宽说明 ISR 里出现了阻塞操作。这两个现象都能直接定位到具体代码比靠猜高效太多。6.2 收敛成一张可扩展的中断跳板表共用中断的场景一旦多起来比如 UART0 接收、UART0 错误、定时器通道共用逐一手写跳板就会变成流水账。我一般会把它统一成一张“中断跳板表”由 App 在启动时一次性注册typedef struct { uint16_t magic; /* 固定为0x5AA5用于校验有效性 */ uint8_t version; /* 布局版本号 */ uint8_t isr_num; /* 表项数量 */ uint32_t isr_addr[8]; /* 每项对应一个中断源的App处理地址 */ } App_IntVectTable;Boot 侧只认这张表的起始地址中断进来后按中断源索引查表。以后 App 想增加一个共用中断只需要改 App 自己的数组定义Boot 代码几乎不用动。这个做法配合跳板 ISR可以让双区中断转发的代码从“每次都要动两个工程”变成“只改 App 一侧”后期维护成本低很多。回顾这个标题相关的经历我最深的教训是RL78 这类 MCU 在双区中断上并没有太多“高级技巧”关键全在跳转前处理干净。外设复位、PIF 清理、状态字写入、地址槽注册每一步都是笨功夫但少一步就会在 App 运行几十分钟后以难以复现的方式回报你。希望这篇文章能让你少走一圈我当时走过的弯路也希望那个 GPIO 测脉冲的办法能帮你把下一次中断问题从玄学变成看得见的波形希望帮到你。本文还有配套的精品资源点击获取
