嵌入式系统中应用复用Bootloader协议库的链接方案及中断疑问

要实现应用无需修改代码，直接引用Bootloader中的通信库函数，可通过以下GCC链接器相关方案实现：

方案1：修改应用的链接器脚本 #

在应用的链接脚本中，直接为通信库的函数符号指定Bootloader中的固定地址，链接器会自动将应用中的函数引用指向该地址，不会将应用内的函数实现链接进二进制。

示例链接脚本代码：

/* 定义Bootloader中通信库函数的固定地址 */
COMM_SEND_ADDR = 0x08001000;  /* 替换为实际地址 */
COMM_RECV_ADDR = 0x08001040;

/* 将符号指向对应地址 */
PROVIDE(comm_send = COMM_SEND_ADDR);
PROVIDE(comm_recv = COMM_RECV_ADDR);

方案2：使用弱符号声明 #

如果应用代码中已经包含通信库函数的实现，可将这些函数声明为弱符号，这样链接器会优先使用链接脚本或命令行指定的外部地址，而非应用内的实现。

示例头文件声明：

/* 在应用的公共头文件中添加弱符号声明 */
extern void comm_send(const uint8_t *data, uint32_t len) __attribute__((weak));
extern uint32_t comm_recv(uint8_t *buf, uint32_t buf_len) __attribute__((weak));

之后配合方案1的链接脚本，或直接用链接命令行选项指定地址即可。

方案3：链接命令行--defsym选项 #

无需修改链接脚本，直接在应用的链接命令中添加--defsym参数，强制指定函数符号的地址：

arm-none-eabi-gcc ... -Wl,--defsym=comm_send=0x08001000,--defsym=comm_recv=0x08001040

Bootloader与应用的中断向量表绑定逻辑取决于硬件机制和库的中断实现方式：

• 硬件层面：嵌入式系统的中断向量表由VTOR（向量表偏移寄存器）指定。Bootloader运行时会将VTOR指向自身的向量表；切换到应用后，应用会将VTOR更新为自己的向量表地址。此时，硬件只会响应应用向量表中注册的中断服务函数（ISR）。

• 库的中断实现场景：

  • 如果库的ISR是静态注册（即Bootloader的向量表中已写入该ISR的地址），那么当应用切换VTOR后，该ISR不会被硬件触发，除非应用的向量表中也将对应中断的入口指向Bootloader中的ISR地址。
  • 如果库采用动态中断回调（即通过函数指针设置中断处理逻辑，而非直接修改向量表），那么要看回调函数的归属：若回调是Bootloader中的函数，应用需确保VTOR指向的向量表中，对应中断的ISR会调用该回调；同时要注意栈上下文、特权级别（如Bootloader为特权级，应用为用户级时需配置MPU允许访问Bootloader地址空间）是否兼容。

• 关键注意点：无论哪种情况，当应用运行时调用Bootloader中的库函数，若库函数触发中断，硬件会使用当前VTOR指向的向量表（即应用的向量表），而非Bootloader的。因此需确保应用向量表中相关中断的ISR配置正确，否则会导致中断无法响应或进入错误处理。

内容的提问来源于stack exchange，提问作者patvax