Arm Cortex-M4 UART中断接收4字节同步序列异常：仅触发一次中断且数据接收混乱

这种UART中断相关的时序问题确实让人头疼，尤其是在和主机做同步的时候，一点点小细节没处理好就会出各种奇怪的问题。我帮你梳理几个最可能的原因和对应的解决办法：

1. 主机端串口数据未真正发送完毕 #

你主机端用TypeScript的uart.write(SYNC_SEQ)后直接await delay(syncDelay)，这里大概率有问题！很多Node.js串口库（比如SerialPort）的write是异步操作——调用后数据只是写入了主机的软件缓冲区，并没有真正通过USB转串口发送到目标板。如果不等数据发完就延迟，目标板可能只收到第一个字节，后续字节还在主机缓冲区里，自然只会触发一次中断。

修改主机端代码，确保所有字节都发送到硬件后再延迟：

const syncWithBootloader = async (syncDelay = 500, timeout = DEFAULT_TIMEOUT) => {
  while (true) {
    await uart.write(SYNC_SEQ); // 等待write操作完成
    await uart.drain(); // 强制刷新缓冲区，确保所有字节发送到硬件
    await delay(syncDelay);
    // ... 后续逻辑
  }
}

2. 目标端ISR未正确处理中断标志与溢出 #

你的中断处理逻辑里，对溢出标志（ORE）的处理可能有疏漏。Cortex-M4的USART溢出标志（ORE）的清除规则比较特殊：仅读取DR寄存器（usart_recv）可能无法完全清除ORE标志，导致后续的接收中断被屏蔽；另外，你需要确保同时使能了接收非空中断（RXNEIE）和溢出中断（OREIE），否则溢出发生时不会触发ISR。

修改目标端ISR代码，规范标志处理流程：

void usart2_isr(void) {
    // 一次性读取SR寄存器，避免处理过程中标志位变化
    uint32_t sr_reg = USART_SR(USART2);
    bool has_overrun = (sr_reg & USART_FLAG_ORE) != 0;
    bool has_data = (sr_reg & USART_FLAG_RXNE) != 0;

    if (has_data || has_overrun) {
        // 读取数据，这会自动清除RXNE标志
        uint8_t received_byte = (uint8_t)usart_recv(USART2);
        
        // 手动清除溢出标志（部分硬件/库需要额外操作）
        if (has_overrun) {
            usart_clear_flag(USART2, USART_FLAG_ORE);
        }

        // 写入环形缓冲区（忽略失败的逻辑可以后续优化）
        (void)ring_buffer_write(&rb, received_byte);
    }
}

同时，在USART初始化代码中，确保同时开启接收中断和溢出中断：

// 原有的USART初始化后添加：
usart_enable_rx_interrupt(USART2);
usart_enable_overrun_interrupt(USART2); // 关键！之前可能漏了这个
nvic_enable_irq(NVIC_USART2_IRQ); // 确保NVIC中断使能

3. 环形缓冲区的原子访问问题 #

你提到环形缓冲区是测试过的，但在ISR和主循环并发访问的场景下，需要确保读写操作的原子性——主循环读取缓冲区时，如果ISR正在写入，可能会读到不一致的状态（比如判断缓冲区有数据，但读的时候数据还没写完）。

修改主循环中的读缓冲区逻辑，添加中断保护：

uint8_t uart_read_byte(void) {
    uint8_t byte = 0;
    // 读取前关闭中断，避免ISR干扰
    irq_disable();
    bool read_success = ring_buffer_read(&rb, &byte);
    irq_enable();
    
    return read_success ? byte : 0xFF; // 失败返回占位符，后续可以加错误处理
}

4. 额外检查点 #

• 确认USART的时钟树配置正确：STM32F446RE的USART2挂载在APB1总线上，APB1的时钟频率会影响波特率计算，确保libopencm3的时钟初始化代码正确（比如rcc_clock_setup_pll(&rcc_hse_8mhz_3v3[RCC_CLOCK_3V3_180MHZ])）。
• 检查NVIC中断优先级：如果USART2的中断优先级太低，可能被其他高优先级中断抢占，导致接收数据延迟或丢失。可以适当提高USART2的优先级：

nvic_set_priority(NVIC_USART2_IRQ, 0x02); // 优先级值越小越高，根据系统调整

按照这些步骤修改后，应该能解决只触发一次中断、数据乱序的问题，同步过程也能稳定完成。

内容来源于stack exchange