ESP32的TaskReadTelegram任务频繁挂起触发看门狗求助

我自制了一台火腿无线电中继器，用ESP32作为控制单元，添加了Telegram远程控制功能，用来获取设备状态信息和执行远程操作。通过FreeRTOS优化了代码效率，但TaskReadTelegram()任务频繁出现挂起，从项目启动就一直困扰我。此前针对WiFi断开场景适配了代码，将每日5-10次的系统重置降到每4-5天1次，但任务仍会挂起并触发系统重启。

不确定是否是getUpdates()方法存在问题需要特殊处理，但该任务逻辑简短，理论上不该出现挂起情况。当前看门狗超时设置为14秒。

任务代码 #

void taskReadTelegram(void *pvParameters)
{
  esp_task_wdt_add(NULL); // 将此任务注册到看门狗，监控任务状态，若未定期重置则检测到阻塞并触发重启
  for (;;)
  {
    esp_task_wdt_reset();
  
    if (WiFiStatus==true)
    {
      
      int numNewMessages = bot.getUpdates(bot.last_message_received + 1);
      vTaskDelay(pdMS_TO_TICKS(500));
      if (numNewMessages != 0)
      {
        Serial.println("got response");
        xQueueSend(colaNumMensajesTelegram, &numNewMessages, 0); // 将消息数通过队列发送到处理任务，由其进行后续处理
        
      }
    }
    else
    {
      Serial.println("ReadTelegram sin conexion");
     
    }
    esp_task_wdt_reset();
    vTaskDelay(pdMS_TO_TICKS(6000)); // 每6秒查询一次是否有新消息
  }
}

触发看门狗时的控制台日志 #

08:20:05:982 -> E (183031094) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
08:20:05:990 -> E (183031094) task_wdt:  - ReadTelegram (CPU 1)
08:20:05:993 -> E (183031094) task_wdt: Tasks currently running:
08:20:05:999 -> E (183031094) task_wdt: CPU 0: Temperaturas
08:20:06:001 -> E (183031094) task_wdt: CPU 1: loopTask
08:20:06:007 -> E (183031094) task_wdt: Aborting.
08:20:06:010 -> 
08:20:06:010 -> abort() was called at PC 0x400ed5a9 on core 0
08:20:06:012 -> 
08:20:06:012 -> 
08:20:06:012 -> Backtrace: 0x40083e99:0x3ffbed1c |<-CORRUPTED
08:20:06:018 -> 
08:20:06:018 -> 
08:20:06:018 -> 
08:20:06:018 -> 
08:20:06:018 -> ELF file SHA256: b56722619dc77b64
08:20:06:021 -> 
08:20:06:340 -> Rebooting...
08:20:06:340 -> ets Jul 29 2019 12:21:46
08:20:06:343 -> 
08:20:06:343 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
08:20:06:348 -> configsip: 0, SPIWP:0xee
08:20:06:348 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
08:20:06:356 -> mode:DIO, clock div:2
08:20:06:356 -> load:0x3fff0030,len:1184
08:20:06:359 -> load:0x40078000,len:13232
08:20:06:362 -> load:0x40080400,len:3028
08:20:06:366 -> entry 0x400805e4

问题分析与解决建议 #

• 限制getUpdates()超时时间：多数Telegram Bot库的getUpdates()默认使用长轮询，若网络不稳定或服务器响应延迟，调用会阻塞超过看门狗阈值。建议显式设置短超时（小于14秒）：

  // 设置超时为10秒，确保在看门狗触发前返回
  int numNewMessages = bot.getUpdates(bot.last_message_received + 1, 0, 10000);
  

• 优化看门狗重置时机：在getUpdates()调用前后都添加看门狗重置，避免调用过程中阻塞超时：

  if (WiFi.isConnected())
  {
    esp_task_wdt_reset();
    int numNewMessages = bot.getUpdates(bot.last_message_received + 1, 0, 10000);
    esp_task_wdt_reset();
    // 后续处理逻辑
  }
  

• 确保任务资源充足：检查TaskReadTelegram的创建参数，栈大小建议至少4096字节，避免因栈溢出导致任务异常；同时调整任务优先级，防止被其他高优先级任务长期抢占。
• 实时检测WiFi状态：替换全局变量WiFiStatus为实时调用WiFi.isConnected()，避免因变量同步问题导致错误执行网络请求。

内容的提问来源于stack exchange，提问作者Javier López