ESP32接入HC-SR04后WiFi/OTA升级故障排查求助

核心故障原因 #

1. 阻塞式IO抢占CPU资源 #

pulseIn() 函数（包括NewPing库底层依赖的类似实现）是阻塞式的：调用后会持续占用CPU等待回波脉冲，直到超时或收到信号。当你缩短检测间隔（小于10秒），CPU会被频繁的阻塞操作占满，导致ESP32的WiFi守护任务、OTA升级的TCP连接处理等关键任务无法获得足够调度时间：

• 路由器因ESP32无法及时响应WiFi心跳包、ACK帧，判定设备离线并断开连接；
• OTA过程中一旦失去连接，升级流程直接中断，设备进入无响应状态（串口、MQTT输出停止，重启按键无效）。

只有当检测间隔拉到10秒、超时设为5ms时，阻塞操作的CPU占比极低，关键任务才有足够时间运行，OTA才能成功。

2. 任务调度优先级冲突 #

ESP32基于FreeRTOS运行，默认情况下，你的主循环（含超声波检测）和OTA/WiFi任务的优先级接近。当超声波检测频繁阻塞主循环时，高优先级的OTA任务无法被及时唤醒，导致升级流程超时失败。

针对性解决建议 #

• 改用非阻塞式超声波检测：
  放弃pulseIn()，改用中断触发回波检测，或者将超声波检测放到单独的FreeRTOS任务中，使用vTaskDelay()而非忙等待控制检测间隔，避免长时间占用CPU。示例思路：

  // 创建超声波检测任务
  void ultrasonicTask(void *pvParameters) {
    while(1) {
      // 触发超声波
      digitalWrite(TRIG_PIN, HIGH);
      vTaskDelay(pdMS_TO_TICKS(10));
      digitalWrite(TRIG_PIN, LOW);
      // 用中断捕获回波，而非阻塞等待
      // ... 处理测距逻辑
      vTaskDelay(pdMS_TO_TICKS(1000)); // 1秒间隔，不阻塞其他任务
    }
  }
  
  // 在setup中启动任务
  xTaskCreatePinnedToCore(ultrasonicTask, "Ultrasonic", 2048, NULL, 1, NULL, 0);
  

• 调整任务优先级：
  将OTA和WiFi相关任务设为高优先级，超声波检测任务设为低优先级（比如优先级1，低于系统默认WiFi任务优先级），确保OTA过程中CPU资源优先分配给升级流程。

• 优化阻塞超时设置：
  如果必须保留pulseIn()，尽量缩短超时时间（比如保持5ms），同时在检测间隔内插入足够的vTaskDelay()，给其他任务留出运行窗口。

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