STM8_Mesh_Control/docs/TIM4_INTERRUPT_DEBUG_RECORD.md

STM8S003F3 TIM4 中断问题排查记录

1. 问题现象

正式主程序烧录后，PB5 程序运行指示灯没有按照约 500 ms 周期闪烁。

此前已经确认：

• 独立 PB5 测试程序可以正常闪烁；
• 测试主程序链接到 0x8800 后，Bootloader 可以正常跳转；
• PB5 GPIO 连接和芯片引脚基本正常；
• 正式主程序最初还存在代码超出应用区的问题，但缩减为最小主循环后，问题依然与系统节拍有关。

2. 逐步排查过程

2.1 先屏蔽 OTA

正式主程序在初始化阶段先调用 OTA 和外部 SPI Flash 初始化。为排除 W25Q80BV 初始化阻塞，临时屏蔽：

OtaManager_Init();
OtaManager_Task();

结果：PB5 仍然没有正常闪烁，因此问题不只在 OTA 初始化。

2.2 再屏蔽蓝牙和 Mesh

继续屏蔽蓝牙状态机、Mesh 任务和上线广播，避免 UART 等待影响主循环。

结果：PB5 仍然没有正常闪烁，蓝牙任务不是唯一原因。

2.3 缩减为最小主循环

最终只保留：

Board_Init()
软件延时
PB5电平翻转

并临时关闭：

• TIM4；
• 全局中断；
• 看门狗；
• UART；
• ADC；
• 蓝牙；
• Mesh；
• 故障管理；
• OTA。

结果：PB5 可以正常闪烁。

由此确认 Bootloader 跳转、主程序入口和 PB5 GPIO 硬件均正常。

2.4 逐步恢复 TIM4

恢复 TIM4 和正式 Board_StatusLedTask() 后，PB5 又变成常亮。

随后使用软件延时配合 TIM4、直接读取 SystemTick_NowMs()、轮询 TIM4_SR 等方法进行区分，最终发现主程序使用 Bootloader 后，应用程序的中断向量不能直接被硬件访问。

3. 最终原因

STM8S003F3 的硬件中断向量地址固定在程序 Flash 起始区域。

官方数据手册规定：

TIM4 IRQ23 向量地址：0x8064
UART1 RX IRQ18 向量地址：0x8050

当前工程的存储布局为：

0x8000 ~ 0x87FF：Bootloader
0x8800 ~ 0x9FFF：Application

主程序虽然链接到 0x8800，但硬件中断不会自动把向量表移动到 0x8800。如果直接在主程序中声明：

void SystemTick_TIM4_ISR(void) __interrupt(23);

硬件发生 TIM4 中断时，仍然访问固定地址 0x8064，而不是主程序向量表中的 0x8864。

因此 Bootloader 跳转正常，但应用程序的 TIM4 中断处理函数没有被正确调用，系统毫秒计数不会正常驱动 PB5 状态灯、超时判断和故障计时。

4. 修正方案

采用 Bootloader 固定向量转发方案：

TIM4硬件中断
    ↓
Bootloader固定向量 0x8064
    ↓
转发到主程序向量 0x8864
    ↓
主程序 SystemTick_TIM4_ISR()
    ↓
SystemTick_TIM4_Handler()

主程序中保留自己的 TIM4 向量入口：

void SystemTick_TIM4_ISR(void) __interrupt(23)
{
    SystemTick_TIM4_Handler();
}

Bootloader 在固定的 IRQ23 入口中跳转到主程序 TIM4 向量槽：

void Bootloader_TIM4_Vector(void) __interrupt(23)
{
    __asm__("jpf 0x8864");
}

这样主程序内部的实际 ISR 地址可以变化，Bootloader 只需要转发到主程序固定向量槽，不需要写死主程序 ISR 的最终代码地址。

5. 验证结果

修正后使用整片固件烧录：

build/stm8_mesh_full.hex

烧录起始地址：

0x8000

PB5 已经能够按照约 500 ms 周期正常闪烁，说明以下链路已经验证通过：

TIM4 → 0x8064 → Bootloader转发 → 0x8864 → 主程序ISR → 系统毫秒计数

6. 经验和教训

6.1 Bootloader 分区不仅影响代码地址，也影响中断体系

把主程序从 0x8000 移动到 0x8800，不能只修改链接地址。还必须同步设计：

• 中断向量转发；
• 应用程序复位入口；
• Bootloader 跳转前的中断清理；
• Bootloader 和主程序外设状态交接。

6.2 独立 GPIO 测试不能证明系统节拍正常

PB5 独立测试程序只验证了：

• Bootloader 能跳转；
• GPIO 能输出；
• LED 硬件正常。

它不能证明 TIM4、UART 中断或应用程序中断向量正常。因此系统功能应分层验证。

6.3 必须先做最小可运行程序

本次通过逐步屏蔽模块，最终定位到：

Bootloader跳转和GPIO正常
业务模块不是第一嫌疑
系统节拍/中断链路异常

以后遇到“主程序没有运行”的问题，应优先建立最小固件：

GPIO + 软件延时
GPIO + 定时器轮询
GPIO + 定时器中断
GPIO + 看门狗
最后再逐个恢复业务模块

6.4 诊断信号的翻转频率必须适合肉眼观察

曾经使用“每 1 ms 翻转一次 PB5”的测试方法。该信号约为 500 Hz，LED 肉眼看起来会接近常亮，容易造成误判。

诊断 LED 建议使用：

• 100 ms；
• 500 ms；
• 1 s；

等肉眼可以明确区分的周期。

6.5 LED 有效电平必须以实物为准

程序注释、原理图标注和实际 LED 驱动极性必须保持一致。调试时应直接测量 MCU 引脚电平，确认：

PB5 = 1 时 LED 是否点亮
PB5 = 0 时 LED 是否熄灭

不能只根据变量名或旧注释判断。

6.6 应用固件大小必须按地址范围判断

主程序的有效空间是：

0x8800 ~ 0x9FFF

不能只看 mesh_relay.bin 的文件大小。必须检查链接 map 中的最高代码地址，确认没有超过 0x9FFF。

6.7 中断向量转发必须随新增中断同步维护

当前已验证 TIM4 转发。后续启用 UART 接收中断时，还必须增加：

UART1 RX IRQ18
固定向量：0x8050
主程序向量槽：0x8850

后续如果 ADC 使用中断，还要增加 ADC1 IRQ22 的转发。

7. 后续恢复顺序

建议严格按照以下顺序继续：

1. 保持 TIM4 中断转发，验证 PB5 正式状态灯；
2. 恢复看门狗并验证不复位；
3. 恢复 UART 初始化和 UART 接收中断转发；
4. 验证 JDY-28M AT 指令通信；
5. 恢复 ADC 电流采样；
6. 恢复蓝牙 Mesh 状态机；
7. 恢复业务协议和故障管理；
8. 最后恢复 OTA 和 W25Q80BV 访问。

每恢复一个模块，都应重新编译、烧录并进行实物验证，不能一次性恢复所有模块后再统一排查。