3、中断检测与捕获技术：GPIO电平检测、定时器轮询、中断服务程序(ISR)注册、状态寄存器监控
升级过程中，最怕什么？
怕写到一半突然断电，怕通信线被误碰，怕某个外设突然发疯把Flash冲了。说白了，就是怕中断——不是程序上的中断，而是物理世界对升级流程的打断。
我做了这么多年嵌入式，见过最惨的一次，是某设备升级到98%时，工人不小心踢掉了电源线。结果呢？整片Flash的启动代码全毁了，最后只能拆机用编程器重烧。从那以后，我对中断检测这件事就特别上心。
3.1 GPIO电平检测：最朴素的“看门狗”
GPIO电平检测，说白了就是拉一根线到某个引脚，然后盯着它看。电平变了，就说明有事发生。
在U-Boot里，我习惯用这种方式检测升级按键或者硬件复位信号。举个例子：
// 检测升级触发引脚（假设是GPIO1_2，低电平有效）
#define UPGRADE_TRIGGER_GPIO (1 << 2)
int check_upgrade_signal(void)
{
u32 val = readl(GPIO1_DATAIN);
if (!(val & UPGRADE_TRIGGER_GPIO)) {
printf("检测到升级触发信号，进入升级模式\n");
return 1;
}
return 0;
}
这段代码很简单，但有个坑——抖动。机械按键按下时，电平会跳好几下。我曾经因为这个，在产线上被折腾了一整天。后来加了个简单的去抖逻辑：
int check_upgrade_signal_debounce(void)
{
int count = 0;
for (int i = 0; i < 10; i++) {
u32 val = readl(GPIO1_DATAIN);
if (!(val & UPGRADE_TRIGGER_GPIO))
count++;
udelay(1000); // 1ms采样一次
}
return (count > 8) ? 1 : 0; // 10次中8次低电平才算有效
}
3.2 定时器轮询：别让CPU空转
GPIO检测有个问题——如果升级过程中CPU一直在忙，你根本没空去读引脚。这时候就需要定时器轮询了。
U-Boot里有个简单的定时器机制，基于芯片的硬件定时器。我通常这样用：
// 伪代码：定时器轮询升级状态
static int upgrade_timeout = 0;
void timer_isr_handler(void)
{
upgrade_timeout++;
// 每次定时器中断，检查一次升级进度
if (check_upgrade_progress() == UPGRADE_FAILED) {
printf("升级超时或失败，触发回滚\n");
trigger_rollback();
}
}
// 在升级开始前注册定时器
void start_upgrade_monitor(int seconds)
{
upgrade_timeout = 0;
// 设置定时器，每秒触发一次
set_timer(1000, timer_isr_handler);
}
你想想看，如果没有这个定时器轮询，万一升级过程中Flash写入卡住了，CPU会一直卡在写循环里。外面的人根本不知道里面发生了什么。定时器就像个“心跳检测”，每隔一段时间确认一下系统还活着。
3.3 中断服务程序(ISR)注册：给中断找个“家”
GPIO检测和定时器轮询，说到底都是“被动”的。真正主动的中断处理，需要注册ISR。
在U-Boot里，中断系统的初始化通常放在board_init()或者arch_early_init_r()里。我个人的做法是：
// 注册一个升级异常中断
int register_upgrade_isr(void)
{
// 假设我们使用IRQ 42作为升级异常中断
int ret = irq_install_handler(42, upgrade_exception_isr, NULL);
if (ret) {
printf("注册升级异常ISR失败！\n");
return -1;
}
// 使能中断
enable_interrupts();
return 0;
}
// ISR实现
static void upgrade_exception_isr(void *arg)
{
// 清除中断标志
writel(0x1, UPGRADE_INT_CLEAR);
// 记录异常信息
gd->upgrade_error_code = readl(UPGRADE_ERROR_REG);
// 设置全局标志，主循环会处理
gd->upgrade_abort_flag = 1;
printf("警告：升级过程中检测到异常！错误码: 0x%x\n", gd->upgrade_error_code);
}
这里有个关键点——ISR要尽可能短。我早期犯过一个错误，在ISR里直接调用了printf和串口输出。结果呢？串口驱动本身可能就在中断上下文里，直接导致死锁。后来我学乖了，ISR里只设标志位，所有输出和复杂操作都放到主循环里。
核心原则：ISR = 记录 + 标记，不做任何可能阻塞的操作。
3.4 状态寄存器监控：硬件给你的“体检报告”
GPIO和定时器都是“软件层面”的检测。但有时候，硬件自己会告诉你出问题了——通过状态寄存器。
比如，Flash控制器有个状态寄存器，里面会记录写保护错误、ECC错误、超时错误等。我建议在升级流程的每个关键步骤后，都去读一下这些寄存器：
// 检查Flash状态寄存器
int check_flash_status(void)
{
u32 status = readl(FLASH_STATUS_REG);
if (status & FLASH_WRITE_PROTECT_ERR) {
printf("Flash写保护错误！请检查硬件保护引脚\n");
return -1;
}
if (status & FLASH_ECC_ERR) {
printf("Flash ECC错误！数据可能已损坏\n");
return -2;
}
if (status & FLASH_TIMEOUT_ERR) {
printf("Flash操作超时！可能是硬件故障\n");
return -3;
}
return 0; // 一切正常
}
我记得有一次，客户反馈升级偶尔会失败。查了三天，最后发现是Flash的电源纹波太大，导致写操作偶尔超时。状态寄存器里清清楚楚地记录了超时错误，但之前的代码根本没去读它。从那以后，我所有的升级代码里都会加上状态寄存器检查。
3.5 四种技术的对比与选择
说了这么多，到底该用哪种？我整理了一个表格，方便你根据实际情况选择：
| 技术 | 适用场景 | 优点 | 缺点 | 我的建议 |
|---|---|---|---|---|
| GPIO电平检测 | 用户触发升级、硬件复位检测 | 实现简单，无需中断资源 | 需要CPU主动轮询，可能漏检 | 配合去抖逻辑，用于升级入口检测 |
| 定时器轮询 | 升级超时监控、进度检查 | 不阻塞主流程，可设置超时 | 精度受定时器分辨率限制 | 用于升级过程中的“心跳”检测 |
| ISR注册 | 紧急异常处理、硬件错误捕获 | 响应快，能处理异步事件 | ISR编写要求高，容易出问题 | 只用于真正的紧急情况，如电源跌落 |
| 状态寄存器监控 | 硬件错误诊断、数据完整性检查 | 直接反映硬件状态，信息准确 | 需要了解具体硬件寄存器定义 | 每个关键操作后都检查一次 |
3.6 综合应用：一个完整的检测框架
在实际项目中，我不会只用一种技术。通常是把它们组合起来：
// 升级主循环中的检测框架
void upgrade_main_loop(void)
{
// 1. 先检查GPIO，看用户是否要取消升级
if (check_upgrade_signal_debounce() == 0) {
printf("用户取消升级，执行回滚\n");
trigger_rollback();
return;
}
// 2. 检查状态寄存器，确认硬件健康
if (check_flash_status() < 0) {
printf("硬件状态异常，中止升级\n");
trigger_rollback();
return;
}
// 3. 执行写入操作
int ret = flash_write(addr, data, len);
// 4. 写入后再检查一次状态寄存器
if (check_flash_status() < 0) {
printf("写入后检测到错误，回滚\n");
trigger_rollback();
return;
}
// 5. 检查全局ISR标志，看是否有异步异常
if (gd->upgrade_abort_flag) {
printf("检测到异步异常，中止升级\n");
trigger_rollback();
return;
}
}
这个框架看起来啰嗦，但每个检查都有它的意义。GPIO检测让用户有“后悔权”，状态寄存器监控确保硬件没撒谎，ISR标志则捕获那些“意外惊喜”。
3.7 本章知识体系
下面这张图，帮你理清这四种技术的关系：
嗯，这四种技术没有哪个是“万能”的。GPIO检测适合做“门卫”，定时器轮询适合做“巡逻兵”，ISR是“特种部队”，状态寄存器则是“体检医生”。把它们组合起来，才能构建一个可靠的升级中断防护体系。