ESP32 WROOM 32U双核心运行LoRa与MQTT任务触发看门狗重启求助

问题分析 #

从错误日志看，CPU1的loopTask触发了任务看门狗，说明默认Arduino loop任务（或绑定在CPU1上的任务）出现长时间阻塞，未及时让出CPU时间片，导致看门狗超时重启。这种情况在网络连接失败、首次启动时触发，大概率是MQTT/4G模块的阻塞式操作（如AT命令等待、MQTT连接重试）占用过多CPU资源，未给任务调度（喂看门狗）留机会。

核心解决步骤 #

1. 用FreeRTOS任务替代默认loop，绑定任务到指定核心 #

避免默认loopTask被阻塞，将LoRa接收和MQTT/4G任务拆分为独立FreeRTOS任务，绑定到不同核心，确保任务调度正常：

TaskHandle_t loraTaskHandle = NULL;
TaskHandle_t mqttTaskHandle = NULL;

void setup() {
  Serial.begin(115200);
  // 初始化LoRa、SIMCOM模块硬件...

  // 创建LoRa接收任务（绑定到CPU0）
  xTaskCreatePinnedToCore(
    loraReceiveTask,
    "LoRaRx",
    4096,  // 栈大小根据实际调整
    NULL,
    1,     // 优先级，低于系统任务
    &loraTaskHandle,
    0
  );

  // 创建MQTT/4G任务（绑定到CPU1，分配足够栈空间）
  xTaskCreatePinnedToCore(
    mqtt4gTask,
    "MQTT4G",
    8192,  // MQTT/TinyGsm需要更大栈
    NULL,
    1,
    &mqttTaskHandle,
    1
  );
}

// 空loop，仅做延迟让出CPU
void loop() {
  vTaskDelay(pdMS_TO_TICKS(1000));
}

2. 重构任务逻辑，消除长时间阻塞 #

所有可能阻塞的操作（如AT命令等待、MQTT连接）必须添加超时限制，并在循环中主动让出CPU：

LoRa接收任务示例：

void loraReceiveTask(void *param) {
  // 初始化LoRa模块...
  while(1) {
    if (LoRa.parsePacket()) {
      // 处理接收的文本字符串
      String received = "";
      while (LoRa.available()) {
        received += (char)LoRa.read();
      }
      // 后续处理逻辑...
    }
    // 必须加入短暂延迟，强制任务切换，喂看门狗
    vTaskDelay(pdMS_TO_TICKS(10));
  }
}

MQTT/4G任务示例（非阻塞重试）：

void mqtt4gTask(void *param) {
  // 初始化TinyGsm、PubSubClient...
  TinyGsm modem(Serial1);
  TinyGsmClient client(modem);
  PubSubClient mqtt(client);
  mqtt.setServer(MQTT_SERVER, MQTT_PORT);

  unsigned long lastReconnectTry = 0;
  const unsigned long reconnectInterval = 5000; // 5秒重试一次

  while(1) {
    if (!mqtt.connected()) {
      if (millis() - lastReconnectTry > reconnectInterval) {
        lastReconnectTry = millis();
        // 尝试连接网络+MQTT，带超时
        if (tryConnectNetworkAndMQTT(&modem, &mqtt)) {
          Serial.println("MQTT Connected");
        } else {
          Serial.println("Connect Failed, Retry Later");
        }
      }
    } else {
      // 处理MQTT消息循环，每次调用后让出CPU
      mqtt.loop();
    }
    // 强制任务切换，避免看门狗触发
    vTaskDelay(pdMS_TO_TICKS(10));
  }
}

bool tryConnectNetworkAndMQTT(TinyGsm *modem, PubSubClient *mqtt) {
  // 网络连接带超时
  if (!modem->isNetworkConnected()) {
    if (!modem->waitForNetwork(10000L)) { // 10秒超时
      return false;
    }
    if (!modem->gprsConnect(APN, GPRS_USER, GPRS_PWD)) {
      return false;
    }
  }
  // MQTT连接带超时
  mqtt->setTimeout(5000);
  if (mqtt->connect(MQTT_CLIENT_ID, MQTT_USER, MQTT_PWD)) {
    mqtt->subscribe("your/topic");
    return true;
  }
  return false;
}

3. 用backtrace定位阻塞函数 #

用ESP32工具链的addr2line解析错误日志中的backtrace地址，找到具体阻塞的函数：

# 替换为你的项目ELF文件路径和backtrace地址
xtensa-esp32-elf-addr2line -e your_project.elf 0x400d5ce9

这能精准定位是哪个函数（如TinyGsm的某个AT命令等待函数）导致长时间阻塞，针对性修改逻辑，加入任务切换。

4. 调整任务优先级与栈大小 #

• 任务优先级设置为1~3（低于系统空闲任务优先级4），避免抢占系统任务CPU时间。
• MQTT/4G任务分配至少8192字节栈空间，防止栈溢出引发异常。

5. 避免中断中执行阻塞操作 #

如果LoRa接收用中断触发，确保中断服务函数（ISR）仅做标记，不执行数据处理，把处理逻辑放到任务中，防止中断阻塞CPU。

关键注意事项 #

• 任何循环逻辑中必须加入vTaskDelay()或taskYIELD()，强制任务切换，让看门狗检测到任务正常运行。
• 禁止使用无超时的阻塞循环（如while(!modem.isNetworkConnected()){} ），必须设置超时上限。
• 定期更新TinyGsm和PubSubClient库，修复已知阻塞问题。

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