RL78 Bootloader与APP共享定时器7中断的实现方法

简介：本资源是一份面向嵌入式开发工程师与RL78单片机进阶学习者的Bootloader与APP协同设计实战指南，聚焦Renesas RL78平台下中断复用与跨区域函数调用这一典型工程难点。文档详细解析901子母工程架构中，如何让Boot区与APP区共用定时器7中断（如在Boot中开启中断并驱动LED闪烁），并解决因APP代码尺寸变化导致入口地址偏移的问题——核心方案是构建动态分支表，在Boot中通过查表跳转调用APP函数，同时规范函数命名（如加app_前缀）避免链接冲突。资源为单个586KB的Word文档（.docx），内容结构清晰，含关键配置说明、流程图示意及CS+开发环境下的实现提示，便于开发者直接复用于实际项目。目前已有1350人学习下载，适合已掌握RL78基础外设编程、正开展双区固件升级或功能解耦开发的中高级工程师参考落地。

1. RL78 Bootloader与APP共用定时器7中断：不是“抢资源”，而是“交班式复用”

你有没有遇到过这种场景：RL78单片机上电后，Bootloader刚点亮LED、跑完校验就跳转到APP，结果APP一启动，定时器7中断突然不响了？或者更玄学的是——LED在Boot阶段闪得挺欢，APP跑起来后反而变慢、卡顿、甚至完全停闪？这不是硬件坏了，也不是中断被屏蔽了，而是你没意识到：RL78的中断向量表是物理固定的，但Boot和APP的中断服务函数（ISR）不能简单“覆盖写”，必须做地址级协同调度。这篇文档讲的，正是901子母工程下，如何让Boot区和Flash APP区共享同一个定时器7中断源，且各自执行不同逻辑（Boot控LED，APP做通信轮询），同时还能让Boot区安全调用APP里动态变化的函数——比如APP升级后函数体变大、入口偏移位移了24字节，Boot仍能精准跳过去。它不依赖CS+自动生成的链接脚本黑匣子，而是靠你亲手写的分支表+重定位跳转实现。适合正在做固件在线升级（FOTA）、双区热切换、或需要Boot阶段预留诊断能力的RL78项目开发者。如果你还在用#ifdef BOOT_MODE硬切代码、或每次改APP都手动算函数地址填进Boot，那这份实操笔记就是你的后悔药。

2. 工程结构与中断复用机制：子母工程怎么拆、怎么连

2.1 901子母工程的本质：两个独立镜像，一套中断向量表

RL78的901子母工程不是传统意义上的“一个工程分两段”，而是两个编译单元共用同一套启动流程和中断向量表定义，但各自拥有独立的.text、.data段起始地址与大小约束。CS+中实际表现为：

• boot.prj：配置为从0x0000开始，占用0x0000–0x3FFF（16KB），包含startup.s、vector_table.asm、boot_main.c
• app.prj：配置为从0x4000开始，占用0x4000–0x1FFFF（112KB），包含app_main.c、app_timer7_isr.c、app_comm.c

关键点在于：中断向量表（位于0x0000–0x00FF）只有一份，由Boot工程生成并固化。APP编译时不会生成新的向量表，而是通过#pragma interrupt声明ISR，并在链接时将函数地址填入Boot工程中预留的“跳转桩”位置。这就是复用的物理基础。

提示：CS+中必须在Boot工程的vector_table.asm里为Timer7中断（向量号0x1A）保留一条jmp指令槽，不能写成nop或reti。APP工程不生成向量表，只生成可重定位的ISR目标文件（.obj）。

2.2 定时器7中断的双阶段接管：Boot先占、APP后接

复用不是“两边同时响应”，而是时间维度上的分时接管：

实现的关键，在于中断向量表中的跳转目标必须可动态修改。CS+默认生成的向量表是只读的，所以我们要手动干预：

1. 在Boot工程vector_table.asm中，将Timer7向量（0x1A）定义为：

   ; vector_table.asm - Timer7 interrupt vector (0x1A) .section .vectors, "a" .org 0x1A jmp timer7_vector_entry ; 不直接jmp到具体函数，而跳到一个可写入口

2. 在Boot的RAM中（如0x1C00）定义可写跳转桩：

   // boot_main.c __attribute__((section(".ram_code"))) void timer7_vector_entry(void) { // 根据当前运行模式，跳转到对应ISR if (is_app_running()) { // 跳转到APP区的ISR（地址来自分支表） ((void(*)(void))branch_table.app_timer7_isr_addr)(); } else { timer7_boot_isr(); // Boot阶段执行 } }

这样，Boot阶段timer7_vector_entry走else分支；APP启动后，is_app_running()返回true，自动跳转到APP的ISR——中断源没变，但服务函数动态切换，零延迟交班。

2.3 分支表设计：为什么不用函数指针数组，而用绝对地址跳转表？

RL78的CC-RL编译器对函数指针支持有限，尤其在跨段调用时易产生PC-relative寻址错误。更可靠的做法是在Boot RAM中维护一张纯地址表，每个条目存APP函数的绝对物理地址（24位）：

// branch_table.h - 定义在Boot工程中 typedef struct { uint32_t app_timer7_isr_addr; // APP的Timer7 ISR入口（24位地址，高8位补0） uint32_t app_update_check_addr; // APP的固件校验函数 uint32_t app_comm_send_addr; // APP的通信发送函数 } app_branch_table_t; // boot_main.c - 分支表实例化在RAM __attribute__((section(".ram_data"))) static app_branch_table_t g_app_branch_table = { .app_timer7_isr_addr = 0x00000000UL, // 初始置0，加载APP后填充 .app_update_check_addr = 0x00000000UL, .app_comm_send_addr = 0x00000000UL };

注意：RL78地址总线为20位（最大1MB），但CC-RL使用24位地址格式（uint32_t），高4位恒为0。分支表必须放在RAM（如0x1C00–0x1C1F），因为Flash不可写。

APP侧需导出这些函数的绝对地址。CS+中通过#pragma address强制指定：

// app_main.c - APP工程 #pragma address = 0x4100 void app_timer7_isr(void) __attribute__((interrupt)); #pragma address = 0x4200 int app_update_check(void); #pragma address = 0x4300 void app_comm_send(const uint8_t* data, uint16_t len);

Boot加载APP镜像后，解析其符号表（或预埋地址映射），将0x4100、0x4200、0x4300填入g_app_branch_table对应字段。后续所有调用均通过((func_ptr)addr)()完成——这是RL78裸机环境下最稳妥的跨区调用方式。

3. 核心代码详解：从向量跳转到APP函数调用的完整链路

3.1 Boot阶段Timer7 ISR：LED控制与状态同步

// boot_timer7_isr.c #include "iodefine.h" #include "boot_main.h" // LED控制：P10引脚，低电平点亮（常见设计） #define LED_PORT P1 #define LED_PIN 0 #define LED_ON() (LED_PORT.PDR.BIT.B0 = 1, LED_PORT.PODR.BIT.B0 = 0) #define LED_OFF() (LED_PORT.PODR.BIT.B0 = 1) // 全局计数器，用于200ms闪烁 static volatile uint16_t led_counter = 0; void timer7_boot_isr(void) __attribute__((interrupt)); void timer7_boot_isr(void) { // 清除Timer7中断标志（RL78手册P12-37） TMKA7.TMK = 0; // 每10ms进一次ISR（假设Timer7配置为10ms周期） led_counter++; if (led_counter >= 20) { // 20 * 10ms = 200ms LED_PORT.PODR.BIT.B0 ^= 1; // 翻转LED led_counter = 0; } // 关键：检查APP是否已就绪，若已跳转则退出此ISR（避免干扰APP） if (is_app_running()) { // 此时应已切换到APP的ISR，此处return防止重复执行 return; } }

逻辑说明：

• TMKA7.TMK = 0是RL78 Timer7中断清标志的唯一正确写法，写1无效，写其他值会触发异常；
• is_app_running()是一个Boot自定义标志，通常设在RAM固定地址（如0x1B00），APP启动后首行代码将其置1；
• 此ISR只在Boot阶段有效，一旦APP运行，timer7_vector_entry会绕过它——不是禁用中断，而是动态路由。

3.2 APP阶段Timer7 ISR：业务逻辑接管

// app_timer7_isr.c - APP工程 #include "iodefine.h" #include "app_main.h" extern volatile uint8_t g_comm_rx_buffer[64]; extern volatile uint16_t g_comm_rx_len; void app_timer7_isr(void) __attribute__((interrupt)); void app_timer7_isr(void) { TMKA7.TMK = 0; // 同样必须清标志 // 示例：每10ms检查一次串口接收缓冲区 if (g_comm_rx_len > 0) { process_uart_frame(g_comm_rx_buffer, g_comm_rx_len); g_comm_rx_len = 0; } // 示例：驱动ADC采样（假设有ADC模块） trigger_adc_conversion(); }

参数说明：

• process_uart_frame()和trigger_adc_conversion()是APP业务函数，地址已填入分支表；
• 此ISR与Boot ISR共享同一硬件中断源（IRQ7）和向量地址（0x1A），但执行流完全不同；
• 因为timer7_vector_entry做了动态分发，APP无需任何向量表操作，专注业务即可。

3.3 Boot调用APP函数：以固件校验为例的完整调用链

// boot_main.c - Boot工程中调用APP的校验函数 #include "branch_table.h" #include "flash_if.h" // 假设APP镜像已加载到0x4000起始的Flash区 #define APP_START_ADDR 0x00004000UL // 步骤1：从APP镜像头部读取函数地址（或预埋在固定偏移） static void load_app_branch_table(void) { const uint32_t* app_header = (const uint32_t*)APP_START_ADDR; // APP镜像头部第5个DWORD存app_update_check地址（约定） g_app_branch_table.app_update_check_addr = app_header[4]; // 第6个DWORD存app_comm_send地址 g_app_branch_table.app_comm_send_addr = app_header[5]; } // 步骤2：安全调用APP校验函数 bool verify_app_firmware(void) { // 检查分支表地址是否有效（非0且在APP区范围内） if (g_app_branch_table.app_update_check_addr == 0x00000000UL || g_app_branch_table.app_update_check_addr < APP_START_ADDR || g_app_branch_table.app_update_check_addr > 0x0001FFFFUL) { return false; // 地址非法 } // 强制类型转换：CC-RL要求函数指针带__far修饰符（24位地址） typedef int (*update_check_func_t)(void) __far; update_check_func_t p_func = (update_check_func_t) g_app_branch_table.app_update_check_addr; // 调用！返回值为0表示校验通过 return (p_func() == 0); } // 步骤3：APP侧的校验函数实现（app_main.c） #pragma address = 0x4200 int app_update_check(void) { // 计算APP区CRC32（0x4000–0x1FFFF） uint32_t crc = calculate_crc32((uint8_t*)0x00004000UL, 0x0001C000UL); return (crc == EXPECTED_APP_CRC) ? 0 : -1; }

关键细节：

• __far修饰符是CC-RL编译器对24位地址函数指针的强制要求，漏写会导致跳转到错误地址；
• calculate_crc32()必须是APP内联实现，不能调用Boot的库函数（段隔离）；
• 地址校验逻辑（< APP_START_ADDR）是血泪经验：曾有开发者因APP镜像烧录偏移错1字节，导致分支表读到全0，Boot调用0x00000000直接锁死。

4. 编译与链接配置：CS+中必须手改的5个关键设置

4.1 Boot工程链接脚本：预留可写跳转桩空间

CS+默认链接脚本（boot.lsl）需显式分配RAM区域给分支表和跳转桩：

; boot.lsl - 修改部分 MEMORY { ROM_BOOT (RX) : ORIGIN = 0x0000, LENGTH = 0x4000 RAM (RWX) : ORIGIN = 0x1C00, LENGTH = 0x0400 ; 1KB RAM for branch table & jump stubs } SECTIONS { .ram_data : { *(.ram_data) . = ALIGN(4); __ram_data_end = .; } > RAM .ram_code : { *(.ram_code) . = ALIGN(4); __ram_code_end = .; } > RAM }

提示：0x1C00是RL78G13常用RAM起始地址，若用G14请查数据手册确认可用RAM范围（如0x1E00）。

4.2 APP工程符号导出：让Boot能“看见”函数地址

CS+中APP工程需启用符号导出功能，否则链接器会优化掉未引用的函数：

1. 右键APP工程 →Properties→C/C++ Build→Settings→Tool Settings→Linker→Symbol Export
2. 勾选"Export all symbols"或手动添加：
   • app_timer7_isr
   • app_update_check
   • app_comm_send
3. 在Linker → Command Line Pattern末尾添加：
   -export=app_timer7_isr,app_update_check,app_comm_send

这样生成的.mot或.hex文件中，会包含这些符号的绝对地址，Boot可通过解析文件获取（或按约定硬编码）。

4.3 中断向量表重定向：绕过CS+自动生成陷阱

CS+的“Auto Generate Vector Table”选项会覆盖你的手动修改。必须关闭：

• Boot工程 →Properties→C/C++ Build→Settings→Tool Settings→Assembler→Vector Table
• 取消勾选"Generate vector table automatically"
• 手动指定vector_table.asm为汇编源文件（右键→Resource Configurations→Exclude from build取消勾选）

否则，每次编译都会把你的jmp timer7_vector_entry覆盖成jmp _undefined_interrupt。

5. 常见问题排查：5条踩坑记录，每条都来自真实翻车现场

5.1 现象：LED在Boot阶段正常闪烁，APP跳转后Timer7中断完全消失

原因：APP工程中未正确定义app_timer7_isr()的__attribute__((interrupt))，或CS+中该函数未被识别为ISR，导致链接器未将其地址填入向量表跳转桩。
解决：检查APP函数声明是否为void app_timer7_isr(void) __attribute__((interrupt));，并在CS+中右键该函数→Go to Declaration确认无语法错误；重新Clean & Build APP工程。

5.2 现象：Boot调用app_update_check()后单片机复位

原因：分支表中填入的地址是APP函数的相对地址（RVA）而非绝对地址（VA）。例如APP链接基址设为0x4000，函数在.text段偏移0x100，则绝对地址是0x4100，但若误填0x0100，跳转即越界。
解决：在CS+的Debug Configurations中启用**"Show Symbol Table"**，查找app_update_check的Address列（显示为0x00004100），复制此值填入分支表，勿用Offset列。

5.3 现象：APP运行后Timer7 ISR执行一次就卡死

原因：APP的app_timer7_isr()中忘记清除TMKA7.TMK标志，导致中断持续触发，抢占所有CPU时间。
解决：RL78所有定时器中断ISR第一行必须是TMKx.TMK = 0（x为定时器号），且必须在reti前执行。检查APP ISR是否遗漏。

5.4 现象：分支表地址正确，但调用APP函数时进入HardFault

原因：CC-RL编译器对跨段调用要求严格，函数指针必须声明为__far，且调用前需确保APP代码段已从Flash加载到RAM（若APP启用XIP需额外处理）。
解决：声明函数指针时务必加__far，如typedef int (*func_t)(void) __far;；若APP代码在Flash执行（XIP），确认Flash读取时序配置正确（FMR寄存器）。

5.5 现象：CS+调试时，Boot能单步进入timer7_vector_entry，但无法进入APP的ISR

原因：CS+调试器默认只加载Boot工程的调试信息，APP的符号未加载，导致断点失效。
解决：在CS+中，Debug Configurations→Debugger→Program→Load additional program files，添加APP工程生成的.elf文件；或在APP ISR首行加__no_operation();，用汇编单步跟踪。

6. 二次开发技巧：让分支表支持动态APP升级与热补丁

6.1 APP镜像头标准化：嵌入函数地址与版本信息

为支持OTA升级，APP镜像头部需固化元数据。在APP工程中定义标准头结构：

// app_header.h - APP工程 #pragma pack(1) typedef struct { uint8_t magic[4]; // "RL78" uint16_t version; // 主版本.次版本 (0x0102 = v1.2) uint32_t timestamp; // 编译时间戳 (Unix time) uint32_t crc32; // 整个APP镜像CRC32（不含header） uint32_t app_timer7_isr; // 函数绝对地址 uint32_t app_update_check; uint32_t app_comm_send; uint32_t app_ota_apply; // OTA补丁应用函数 } app_header_t; // app_main.c - 在APP起始地址放置头 #pragma address = 0x00004000 const app_header_t g_app_header = { .magic = {'R','L','7','8'}, .version = 0x0100, .timestamp = __DATE_UNIX__, .crc32 = 0x00000000UL, // 构建脚本计算后填入 .app_timer7_isr = 0x00004100UL, .app_update_check = 0x00004200UL, .app_comm_send = 0x00004300UL, .app_ota_apply = 0x00004400UL };

Boot加载APP时，直接读取0x4000处的g_app_header，提取所有函数地址——彻底摆脱手动填表，升级APP只需烧录新镜像。

6.2 Boot端分支表自动加载：从APP头解析地址

// boot_flash_loader.c #include "app_header.h" bool load_app_branch_table_from_header(uint32_t app_base_addr) { const app_header_t* hdr = (const app_header_t*)app_base_addr; // 魔数校验 if (hdr->magic[0] != 'R' || hdr->magic[1] != 'L' || hdr->magic[2] != '7' || hdr->magic[3] != '8') { return false; } // 版本兼容性检查（可选） if ((hdr->version >> 8) != 0x01) { // 主版本必须为1 return false; } // 填充分支表 g_app_branch_table.app_timer7_isr_addr = hdr->app_timer7_isr; g_app_branch_table.app_update_check_addr = hdr->app_update_check; g_app_branch_table.app_comm_send_addr = hdr->app_comm_send; g_app_branch_table.app_ota_apply_addr = hdr->app_ota_apply; return true; }

6.3 热补丁机制：APP函数地址可运行时更新

某些场景需在APP运行中动态替换函数（如修复紧急Bug）。可在APP中预留一个“热补丁槽”：

// app_patch.c - APP工程 __attribute__((section(".patch_section"))) static uint32_t g_patch_table[8] = {0}; // 8个可热更新函数地址 // Boot提供更新接口 void app_update_patch(uint8_t index, uint32_t new_addr) { if (index < 8) { g_patch_table[index] = new_addr; } } // APP业务函数改为间接调用 void app_comm_send_wrapper(const uint8_t* data, uint16_t len) { if (g_patch_table[0] != 0) { // 调用补丁函数 ((void(*)(const uint8_t*, uint16_t))g_patch_table[0])(data, len); } else { app_comm_send_real(data, len); // 原函数 } }

Boot通过分支表调用app_update_patch(0, 0x4500)即可热替换app_comm_send——无需重启，不中断业务。

从那以后我每次做RL78 Bootloader项目，都会在APP工程里强制加一个app_header_t，并用Python脚本在构建后自动计算CRC填入；分支表初始化函数必加地址合法性校验，哪怕多写3行代码。因为RL78的中断和跳转是裸金属级操作，没有操作系统兜底，一个地址错，整台设备就变砖。希望帮到你。

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