ESP32-S3启用WiFi与EVE2显示屏触发WDT问题咨询

核心结论 #

大概率是WiFi与SPI主设备的资源/中断冲突导致的问题：ESP32-S3的WiFi模块运行时会占用部分硬件资源或触发高优先级中断，干扰了EVE2显示屏的SPI通信流程，使得EVE_execute_cmd中的循环无法正常退出，最终触发看门狗超时。

具体排查与修复步骤 #

1. 检查SPI硬件资源分配冲突

• 确认显示屏使用的SPI主机（HSPI/VSPI等）是否与WiFi共享引脚或DMA通道：ESP32-S3的GPIO6-11默认用于SPI Flash，若WiFi复用了这些引脚的外设功能，或显示屏SPI占用了WiFi依赖的DMA通道，会直接引发冲突。
• 核对你的GPIO配置，确保显示屏的SCK/MOSI/MISO/CS引脚未与WiFi默认引脚重叠。
• 代码中检查SPI初始化参数，若开启了DMA，确认DMA通道未被WiFi占用（可通过ESP-IDF的spi_bus_initialize参数指定独立DMA通道）。

2. 调整SPI任务优先级与超时机制

• EVE_execute_cmd通常循环等待EVE设备的STATUS寄存器响应，WiFi的高优先级中断会频繁打断该循环，导致等待超时触发WDT。可通过FreeRTOS提升SPI任务优先级：

  vTaskPrioritySet(xSPI_TaskHandle, tskIDLE_PRIORITY + 3);
  

• 给EVE_execute_cmd的循环添加超时判断，避免无限阻塞：

  uint32_t timeout = 500; // 500ms超时阈值
  while ((EVE_read_reg(REG_STATUS) & STATUS_CMD_BUSY) && timeout--) {
      vTaskDelay(pdMS_TO_TICKS(1));
  }
  if (timeout == 0) {
      ESP_LOGE("EVE", "Command execute timeout, resetting SPI bus");
      // 此处添加SPI总线重置逻辑
  }
  

3. 用互斥锁隔离WiFi与SPI操作

• 使用FreeRTOS互斥锁确保同一时间只有一个模块访问SPI总线，避免并行冲突：

  // 初始化互斥锁
  SemaphoreHandle_t xSPIMutex = xSemaphoreCreateMutex();
  
  // WiFi操作前获取锁
  xSemaphoreTake(xSPIMutex, portMAX_DELAY);
  // WiFi连接/数据收发代码
  xSemaphoreGive(xSPIMutex);
  
  // SPI操作前获取锁
  xSemaphoreTake(xSPIMutex, portMAX_DELAY);
  EVE_execute_cmd(...);
  xSemaphoreGive(xSPIMutex);
  

4. 排查电源稳定性问题

• WiFi激活时会瞬间增加电流消耗，若电源供电不足，会导致显示屏SPI通信不稳定。建议使用功率≥5V/2A的电源模块，或在WiFi启动时暂时降低显示屏亮度以减少功耗。

5. 定位EVE_execute_cmd阻塞点

• 在循环中添加调试日志，输出STATUS寄存器值，确认是设备无响应还是通信错误：

  while (1) {
      uint8_t status = EVE_read_reg(REG_STATUS);
      ESP_LOGI("EVE_DEBUG", "Current STATUS: 0x%02X", status);
      if (!(status & STATUS_CMD_BUSY)) break;
      vTaskDelay(pdMS_TO_TICKS(1));
  }
  

• 若日志显示STATUS值始终未变化，说明SPI通信被WiFi中断打断，需进一步隔离硬件资源。

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