STM32F103复位后无法进入UART中断问题求助

这问题我之前帮不少开发者排查过，复位后没法进入HAL_UART_RxCpltCallback通常逃不过这几个常见原因，咱们一个个来捋：

• 回调函数内忘记重新启动中断接收
  HAL的UART中断接收是单次触发的——调用HAL_UART_Receive_IT只会启动一次中断检测，当回调函数触发后，必须再次调用这个函数才能开启下一轮的接收监听。如果你的代码只在初始化阶段调用了一次HAL_UART_Receive_IT，那复位后第一次接收完成触发回调后，后续就不会再触发了。正确的做法是在回调里补上下一次启动：

  void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
  {
      if(huart->Instance == USART1) // 对应你的UART实例
      {
          // 先处理接收到的数据
          process_rx_data(rx_data);
          // 必须重新启动中断接收，否则后续不会触发回调
          HAL_UART_Receive_IT(&huart1, &rx_data, 1);
      }
  }
  

• 复位后UART初始化/中断启动时机错误
  要确保HAL_UART_Receive_IT是在UART完全初始化完成后调用的，而且复位后这段代码确实被执行到了。比如有些开发者会把启动中断的代码放在某个只执行一次但复位后分支没进入的逻辑里，或者UART的时钟、GPIO配置在复位后没正确初始化（比如外设时钟忘记重新使能），都会导致UART根本无法工作，自然触发不了中断。

• 中断优先级配置问题
  复位后NVIC的配置会重置，要确认UART对应的中断已经被正确启用，且优先级设置合理：

  // 示例：USART1中断配置
  HAL_NVIC_SetPriority(USART1_IRQn, 2, 0); // 优先级根据你的系统调整
  HAL_NVIC_EnableIRQ(USART1_IRQn);
  

  如果UART中断优先级被设得过低，可能被其他高优先级中断长期抢占，或者优先级配置冲突导致中断被屏蔽，都没法触发回调。

• HAL UART状态机异常
  复位后UART句柄的状态（huart->State）可能处于错误状态（比如HAL_UART_STATE_ERROR），这时候调用HAL_UART_Receive_IT会直接失败。可以在启动中断前检查状态，必要时重置UART：

  if(huart1.State != HAL_UART_STATE_READY)
  {
      HAL_UART_DeInit(&huart1);
      MX_USART1_UART_Init(); // 重新初始化UART
  }
  HAL_UART_Receive_IT(&huart1, &rx_data, 1);
  

  另外别忘了检查HAL_UART_ErrorCallback是否被触发——复位后如果出现帧错误、溢出错误等，状态机会卡住，这时候需要在错误回调里处理并重新启动接收。

• 硬件层面的异常
  最后排除硬件问题：复位后RX引脚是否接触良好？外部设备在复位后有没有正常发送数据？可以用示波器测量RX引脚的波形，确认有数据输入；也可以短接TX和RX做回环测试，看是否能触发回调，排除硬件链路的问题。

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