简介：本资源是一份面向嵌入式开发工程师与RL78单片机进阶学习者的实战技术文档，聚焦Renesas RL78平台下Bootloader与应用程序（APP）协同设计的核心难点：中断资源共享与跨区域函数调用。文档以901子母工程为背景，详细解析如何在boot区和app区共用定时器7中断（如实现LED闪烁），并解决因APP代码尺寸变化导致入口地址偏移的问题——通过构建动态分支表实现boot区对flash中APP函数的安全跳转，同时规范函数命名前缀（如app_）避免链接冲突。资源为单个586KB的Word文档（.docx），内容涵盖原理说明、配置要点及CS+开发环境下的关键操作指引，结构紧凑、实操性强。目前已有1350人学习下载，适合已掌握RL78基础开发、正开展Bootloader定制或OTA升级方案设计的中高级开发者参考复用。
1. RL78 Bootloader与APP共用定时器7中断：不是“抢资源”，而是“交班式协同”
你有没有遇到过这种场景：RL78单片机上电后，Bootloader刚点亮LED、跑完校验，正准备跳转到APP——结果APP一启动，定时器7中断突然不响了，LED停闪，串口日志断在半截？或者更玄学的是：Bootloader里中断能进、LED能闪；APP里同样配置定时器7，却死活不触发，查寄存器发现INTEN7=1、IFLAGE7=0，但中断向量表里两个函数名还撞车报重定义？这不是硬件坏了，是典型的Boot+APP中断协同没做对。这份文档讲的，就是901子母工程下，如何让Boot和APP共享同一个物理中断源（TMR7），且各自执行独立逻辑——Boot阶段用它驱动LED呼吸，APP阶段用它做毫秒级任务调度，中间不冲突、不覆盖、不重启。核心不在“怎么开中断”，而在“谁管向量、谁清标志、谁关总使能”。它适合正在做固件升级方案、需要Boot阶段保留基础外设响应能力（比如按键唤醒、低功耗定时唤醒）、又不想为APP单独预留中断号的RL78开发者。尤其适用于CS+ IDE环境下使用CC-RL编译器、Flash分段烧录的工业控制类项目。
2. 架构设计：子母工程下的中断复用本质是“向量接管”而非“寄存器复用”
2.1 子母工程结构与内存布局：为什么必须区分Boot和APP的中断入口
RL78的901子母工程不是简单地把两段代码塞进一个工程，而是通过CS+的“Multi-Image Project”机制，在链接阶段就将Boot和APP分别映射到Flash不同扇区。典型布局如下（以R5F100LE为例）：
| 区域 | 起始地址 | 大小 | 用途 |
|---|---|---|---|
| Boot | 0x00000 | 8KB | 启动代码、校验逻辑、USB/UART下载协议、LED控制 |
| APP | 0x002000 | 48KB | 主应用逻辑、传感器采集、通信协议栈 |
关键点在于：中断向量表是全局唯一的，固定位于0x00000–0x0003F（前64字节）。无论Boot还是APP，TMR7中断向量（地址0x0002A–0x0002B）只能指向一个函数地址。因此，“共用中断”的真实含义是：Boot阶段由Boot的ISR处理，APP运行时由APP的ISR处理，但向量地址始终指向Boot区的跳转桩（trampoline）。这个跳转桩负责判断当前运行状态，并动态跳转到对应区域的ISR。
提示：不要试图在APP中重新写
#pragma interrupt (vect=0x2A)去覆盖向量——CS+链接器会报错“vector table conflict”。正确做法是Boot区永久持有向量，APP只提供可被调用的ISR实体。
2.2 中断向量跳转桩：Boot区的tmr7_isr_trampoline实现
在Boot工程的startup.s或interrupt_handlers.c中，必须定义一个固定的向量入口函数，它不直接处理业务，而是做状态路由：
// boot/src/interrupt_handlers.c #include "r_cg_macrodriver.h" #include "r_cg_cgc.h" // 声明APP区的ISR函数（外部符号，地址由分支表提供） extern void app_tmr7_isr(void); // 全局状态标志：0=Boot模式，1=APP模式 volatile uint8_t g_boot_app_mode = 0; // TMR7中断向量桩：固定位于0x0002A，由Boot区永久占用 #pragma interrupt (vect=0x2A, enable) void tmr7_isr_trampoline(void) { // 1. 清除TMR7中断标志（必须在跳转前！否则APP ISR可能收不到二次触发） IAWCTL &= ~0x01U; // 禁用中断嵌套（RL78要求） TMRA0IF &= ~0x01U; // 清TMR7 IF标志 // 2. 根据运行模式跳转 if (g_boot_app_mode == 0) { // Boot模式：执行Boot自己的LED闪烁逻辑 led_blink_toggle(); } else { // APP模式：跳转到APP区的ISR（地址来自分支表） // 注意：此处不能直接调用app_tmr7_isr()，因为链接时地址未知 // 必须通过函数指针跳转，指针值由分支表初始化 extern void (* const g_app_isr_table[])(void); if (g_app_isr_table[0] != NULL) { g_app_isr_table[0](); // 调用APP的TMR7 ISR } } IAWCTL |= 0x01U; // 恢复中断嵌套 }这段代码的关键逻辑在于：
- 清标志必须在跳转前完成：RL78的TMRxIF标志是写1清零，若在APP ISR中再清，Boot桩已退出，可能导致中断丢失；
g_boot_app_mode是状态开关：Boot初始化完成后置1，APP跳转前由Boot设置；g_app_isr_table[0]是分支表首项：存储APP侧app_tmr7_isr的实际运行地址，非编译期地址。
2.3 分支表设计：解决APP函数地址漂移的核心机制
APP函数地址随代码增减而变化，硬编码绝对地址必然失效。分支表是Boot与APP之间的“地址契约”，其结构需满足三点：
- 位置固定：放在Boot区末尾（如0x01E00），不随Boot代码变化；
- 格式标准：每个条目为16位函数地址（RL78为16位地址总线）；
- 可更新性：APP编译后生成的
.map文件中提取地址，由脚本注入Boot二进制。
分支表在Boot中的定义示例（boot/inc/branch_table.h）：
// 分支表起始地址：0x01E00（需在linker script中显式指定） #pragma section _BRANCH_TABLE const uint16_t g_app_isr_table[] = { 0x0000U, // [0] app_tmr7_isr 0x0000U, // [1] app_uart_rx_isr 0x0000U, // [2] app_adc_complete_isr // ... 更多APP函数入口 }; #pragma section对应的链接脚本片段（boot/link.x）需强制定位：
SECTIONS { .branch_table 0x01E00 : { *(._BRANCH_TABLE) } > FLASH }APP侧则需导出符号供地址提取：
// app/src/main.c #pragma section _APP_ISR void app_tmr7_isr(void) __attribute__((section(".app_isr"))); #pragma section void app_tmr7_isr(void) { static uint16_t cnt = 0; cnt++; if (cnt >= 100) { // 100ms触发一次 sensor_poll(); cnt = 0; } }注意：
.app_isr段需在APP的linker script中分配到实际Flash地址（如0x002100），并确保该地址不与Boot区重叠。
3. 编译与烧录：CS+环境下子母工程的三步落地法
3.1 工程配置：启用Multi-Image并隔离符号空间
在CS+中创建Multi-Image Project后，必须进行三项关键设置：
- Boot工程属性 → Toolchain → CC-RL → [Linker] → Multi-Image Settings：勾选“Enable Multi-Image”，设置Boot Image Base Address为
0x00000； - APP工程属性 → Toolchain → CC-RL → [Linker] → Memory Layout：将
ROM起始地址设为0x002000，大小设为0x0C000（48KB）； - 符号隔离：在APP工程的
[Compiler] → [Preprocessor] → User Defined Macros中添加APP_PREFIX=app_，并在所有APP函数声明前加宏：
// app/inc/app_common.h #define CONCAT(a, b) a ## b #define APP_FUNC(name) CONCAT(APP_PREFIX, name) void APP_FUNC(tmr7_isr)(void); // 展开为 app_tmr7_isr这样既避免与Boot函数名冲突，又保持调用语义清晰。
3.2 地址提取与分支表注入：Python脚本自动化流程
每次APP代码变更后，必须更新Boot区的分支表。手动查.map文件易出错，推荐用Python脚本自动完成：
# update_branch_table.py import re import sys def extract_app_address(map_file, symbol): """从.map文件提取symbol的加载地址（Load Address）""" with open(map_file, 'r') as f: content = f.read() # 匹配类似：app_tmr7_isr 0x000021a0 0x0000001a ... pattern = rf'{symbol}\s+0x([0-9a-fA-F]+)\s+' match = re.search(pattern, content) return int(match.group(1), 16) if match else None def inject_to_boot_bin(boot_bin, table_offset, addr_list): """将地址列表写入boot.bin指定偏移处（小端序）""" with open(boot_bin, 'r+b') as f: for i, addr in enumerate(addr_list): offset = table_offset + i * 2 f.seek(offset) # 写入16位小端地址 f.write(addr.to_bytes(2, 'little')) if __name__ == '__main__': if len(sys.argv) != 4: print("Usage: python update_branch_table.py <app.map> <boot.bin> <table_offset>") sys.exit(1) app_map = sys.argv[1] boot_bin = sys.argv[2] table_offset = int(sys.argv[3], 0) # 提取APP函数地址 addresses = [ extract_app_address(app_map, 'app_tmr7_isr'), extract_app_address(app_map, 'app_uart_rx_isr'), extract_app_address(app_map, 'app_adc_complete_isr'), ] inject_to_boot_bin(boot_bin, table_offset, addresses) print(f"Branch table updated at offset 0x{table_offset:X}")执行命令：
python update_branch_table.py ./app/Debug/app.map ./boot/Debug/boot.bin 0x1E00此脚本应集成到CS+的“Post-build steps”中，确保每次APP编译后自动更新Boot二进制。
3.3 烧录顺序与校验：先Boot后APP，且APP必须带校验头
烧录时严格遵循顺序：
- 先烧录Boot.bin（0x00000起始）；
- 再烧录APP.bin（0x002000起始），但APP.bin需前置4字节校验头：
- 字节0-1：APP代码长度（小端）；
- 字节2-3：APP代码CRC16（XMODEM算法）。
Boot在跳转前会验证此头，防止损坏APP执行。校验头生成脚本（gen_app_header.py）需与上述脚本配套使用。
提示：CS+的Flash Programmer不支持自动拼接header，必须用外部工具（如
dd或自研工具）生成最终APP.hex。
4. 避坑指南：RL78 Boot-APP中断协同的5个血泪经验
4.1 现象：中断能进，但LED只闪一次就停
原因：Boot桩中清TMR7 IF标志的位置错误。若在if/else分支内清标志，APP模式下Boot桩退出后，APP ISR执行完毕未清标志，导致IF持续为1，但中断已被CPU屏蔽（因未执行RETI指令前IF不自动清）。
解决：严格按本文2.2节代码，在跳转前统一清标志，且确保IAWCTL嵌套控制正确。
4.2 现象：APP跳转后TMR7中断完全失灵，调试器显示PC停在0x00000
原因：分支表地址写错，g_app_isr_table[0]指向非法地址（如0x0000），导致跳转后执行空操作，最终触发非法指令复位。
解决：用CS+的“Memory Browser”检查0x01E00处的16位值是否为APP中app_tmr7_isr的真实地址（非.map中的Symbol Address，而是Load Address）。
4.3 现象：Boot阶段LED正常闪烁，APP启动后闪烁频率变快一倍
原因：APP中误开启了TMR7的重复启动（如TMR7EN = 1后又调R_TAU0_ChannelStart()），导致同一硬件定时器被Boot和APP各启动一次，中断频率叠加。
解决：APP初始化时必须先停止TMR7（TMR7EN = 0），再配置重载值、启动；Boot阶段也应在跳转前关闭TMR7（TMR7EN = 0），由APP全权管理。
4.4 现象：CS+编译报错“undefined reference toapp_tmr7_isr”
原因：APP工程未正确导出符号。CC-RL默认不导出static函数，且若app_tmr7_isr声明在.c文件内未加extern声明，Boot工程无法链接。
解决：在APP的app_common.h中添加extern void app_tmr7_isr(void);，并在Boot的branch_table.h中extern声明该函数（仅用于编译检查，不实际调用）。
4.5 现象：串口打印显示g_boot_app_mode始终为0，APP ISR从未执行
原因：Boot跳转前未设置该标志。常见于跳转代码写成((void(*)(void))APP_START_ADDR)();，但忘记在跳转前执行g_boot_app_mode = 1;。
解决：跳转前必须原子化设置模式标志，并加内存屏障（__no_operation();）防止编译器优化重排。
5. 二次开发：从“调用APP函数”到“构建Boot-APP服务总线”
5.1 扩展分支表：支持APP动态注册回调
当前分支表是静态的，APP函数地址在编译期固化。若需APP运行时动态注册新功能（如OTA升级后加载新驱动），可将分支表升级为“服务总线”：
// boot/inc/service_bus.h typedef enum { SVC_TMR7_ISR = 0, SVC_UART_SEND, SVC_FLASH_WRITE, SVC_MAX } svc_id_t; typedef struct { uint16_t (*handler)(uint16_t, void*); // 统一签名：返回状态码，参数透传 uint16_t version; // 版本号，用于兼容性检查 } svc_entry_t; extern const svc_entry_t g_svc_table[SVC_MAX];APP启动后，通过Boot提供的svc_register()函数注册自身服务：
// app/src/main.c uint16_t app_flash_write_handler(uint16_t len, void* data) { return flash_program(0x004000, data, len) ? 0 : 1; } void app_init(void) { // 注册到Boot的服务总线 svc_register(SVC_FLASH_WRITE, app_flash_write_handler, 0x0100); }Boot侧svc_register()实现为：
// boot/src/service_bus.c void svc_register(svc_id_t id, uint16_t (*handler)(uint16_t, void*), uint16_t ver) { if (id < SVC_MAX) { // 写入Boot区RAM中的服务表（非Flash，可动态改） g_svc_table[id].handler = handler; g_svc_table[id].version = ver; } }这样，Boot就能在任意时刻调用g_svc_table[SVC_FLASH_WRITE].handler(len, buf)，无需关心APP地址变化。
5.2 中断服务解耦：引入消息队列替代直接调用
直接调用APP ISR存在风险：若APP ISR执行时间过长，会阻塞Boot桩，影响Boot自身实时性（如USB中断响应）。更健壮的做法是Boot桩只发消息，APP轮询处理：
// boot/src/interrupt_handlers.c #pragma interrupt (vect=0x2A) void tmr7_isr_trampoline(void) { TMRA0IF &= ~0x01U; // 清标志 if (g_boot_app_mode == 0) { led_blink_toggle(); } else { // 发送消息到APP消息队列（环形缓冲区） msg_queue_send(&g_app_msg_q, MSG_TMR7_TICK, 0); } } // app/src/main.c void app_task_loop(void) { msg_t msg; while (msg_queue_receive(&g_app_msg_q, &msg, 0) == 0) { switch (msg.id) { case MSG_TMR7_TICK: sensor_poll(); break; } } }此模式下，Boot桩执行时间恒定<1μs，APP在主循环中处理业务，彻底解耦实时性与功能性。
5.3 调试技巧：用CS+的“Peripheral View”实时观测中断状态
RL78的中断调试不能只看代码，必须结合硬件视图：
- 在CS+ Debug模式下，打开
View → Peripheral View → Interrupt，观察INTEN7（使能）、IFLAG7（挂起）、IPR7（优先级）三栏实时值； - 若
IFLAG7=1但不进中断，检查INTEN7是否为0（被APP意外关闭）； - 若
IFLAG7=0但应触发，检查TMR7的CNT是否卡死（如预分频配置错误导致溢出周期过长）。
我每次遇到中断不进，第一反应不是翻代码，而是打开Peripheral View盯住这三栏——80%的问题当场定位。从那以后我每次新建RL78工程，都强制在Debug配置中勾选“Show Peripheral View on debug start”，省下至少两小时排查时间。
希望帮到你。
本文还有配套的精品资源，点击获取
