文章来源说明本文由 ZeroOne AI 整理发布官网与 CSDN 双端同步首发原文见 www.zeroone-ai.com。一、问题现象在将原有 ESP32 工程升级到 ESP-IDF v5.5 后程序烧录成功但是 ESP32 上电后不断重启。 串口监视器可以看到类似以下日志I (388) boot: Loaded app from partition at offset 0x10000 I (388) boot: Disabling RNG early entropy source... I (398) cpu_start: Multicore appE (398) cpu_start: Running on single core variant of a chip, but app is built with multi-core support. E (401) cpu_start: Check that CONFIG_FREERTOS_UNICORE is enabled in menuconfigabort() was called at PC 0x400d27a4 on core 0随后出现Backtrace: ... start_other_core ... call_start_cpu0设备进入启动 → 异常 → abort → 重启 → 启动 → 异常 → 重启的循环。二、问题定位从日志中最重要的一句话是Running on single core variant of a chip, but app is built with multi-core support.它的含义是 当前实际运行的芯片是单核芯片但是编译出来的应用程序按照多核 ESP32 进行了编译。 本项目使用的是 ESP32-SOLO-1 ESP32-SOLO-1 属于单核 ESP32。 因此程序启动时ESP-IDF 发现实际硬件单核 编译配置双核于是启动代码尝试启动第二个 CPUstart_other_core()但是实际芯片没有第二个 CPU因此调用abort()最终导致芯片复位。 所以这次重启并不是普通的看门狗电源不稳定UDP 通讯异常内存不足应用程序死循环而是系统启动阶段的 CPU 配置不匹配。三、为什么以前版本可以正常运行本项目原来使用旧版本 ESP-IDF 时可以正常运行。 升级到ESP-IDF v5.5之后出现问题。 这说明需要重点检查 ESP-IDF 升级以后工程配置是否发生变化。 尤其是sdkconfig build/ CMakeCache.txt ESP-IDF Target FreeRTOS CPU 配置这些配置并不是简单地替换 ESP-IDF 目录就可以保证完全一致。四、首先确认 ESP32 TargetESP32-SOLO-1 使用的 ESP-IDF Target 仍然是esp32这里容易产生误解。 ESP32-SOLO-1 虽然是单核但是它不是esp32c3也不是esp32s2因此工程 Target 应该仍然是CONFIG_IDF_TARGETesp32可以使用idf.py show-target检查当前工程。 如果 Target 配置异常可以重新设置idf.py set-target esp32五、为什么 menuconfig 中找不到 CONFIG_FREERTOS_UNICORE这是本次问题排查中比较容易困惑的一点。 日志明确提示Check that CONFIG_FREERTOS_UNICORE is enabled in menuconfig但是在 ESP-IDF v5.5 的 SDK Configuration Editor 中却找不到Run FreeRTOS only on first core也就是CONFIG_FREERTOS_UNICORE这时候不能简单认为“找不到配置项就是没有问题”。 需要首先确认 当前 menuconfig 是否正常加载了这个工程。 因为本项目同时出现了 CMakeCache 错误。六、真正影响 menuconfig 的 CMakeCache 错误升级/复制工程以后出现了如下错误CMake Error: The current CMakeCache.txt directory E:/ESP32/Work/softAP-fixport9999/build/CMakeCache.txt is different than the directory e:/ESP32/Work/softAP/build where CMakeCache.txt was created.随后又出现The source E:/ESP32/Work/softAP-fixport9999/CMakeLists.txt does not match the source E:/ESP32/Work/softAP/CMakeLists.txt used to generate cache.这个问题非常关键。 原来的工程目录是E:/ESP32/Work/softAP后来工程变成E:/ESP32/Work/softAP-fixport9999但是build/CMakeCache.txt仍然保存着旧工程路径。 因此 CMake 发现旧工程 E:/ESP32/Work/softAP当前工程 E:/ESP32/Work/softAP-fixport9999两者不一致于是拒绝继续配置。 最终导致SDK Configuration Editor也无法正常运行。 因此在检查 CONFIG_FREERTOS_UNICORE 之前必须先解决 CMake 工程缓存问题。七、正确清理工程最简单可靠的方法是删除当前工程的build/例如E:\ESP32\Work\softAP-fixport9999\build删除整个 build 目录。 也可以执行idf.py fullclean但是如果工程目录已经发生过变化直接删除 build 往往更加可靠。 然后重新配置idf.py reconfigure再重新编译idf.py build最后烧录idf.py flash八、推荐的完整操作流程对于本项目建议按照下面顺序操作。 1. 进入正确工程目录cd E:\ESP32\Work\softAP-fixport99992. 删除旧的 build 删除build/3. 确认 Targetidf.py show-target确保esp32如果不是idf.py set-target esp324. 重新生成 CMakeidf.py reconfigure5. 打开配置界面idf.py menuconfig此时再检查 FreeRTOS 相关配置。 6. 重新编译idf.py build7. 烧录idf.py flash8. 查看启动日志idf.py monitor九、不要直接修改应用代码解决这个问题这个问题发生在cpu_start阶段。 也就是说程序甚至还没有真正进入正常的应用逻辑。 因此下面这些代码通常不是解决方案while(1)或者vTaskDelay()也不是 UDP、Wi-Fi、TCP、GPIO 等应用代码导致的。 正确的解决方向应该是芯片型号 ↓ ESP-IDF Target ↓ sdkconfig ↓ FreeRTOS CPU 配置 ↓ 重新生成 CMake ↓ 重新编译 ↓ 重新烧录十、如何判断问题是否已经解决解决以后启动日志不应该再出现Running on single core variant of a chip, but app is built with multi-core support.也不应该再出现start_other_core以及abort() was called正常情况下应该继续进入应用程序初始化例如app_main()以及项目自己的WiFi init UDP init GPIO init ...十一、建议保留一份稳定配置由于这个项目以前在旧版 ESP-IDF 下运行正常而升级 ESP-IDF 后出现配置问题后续建议将关键配置明确保存。 可以在工程中维护sdkconfig.defaults并记录ESP-IDF版本 芯片型号 Target FreeRTOS配置 Flash配置 Partition Table Wi-Fi配置例如ESP32-SOLO-1 Target: esp32 ESP-IDF: v5.5这样以后更换电脑、复制工程或者升级 ESP-IDF 时可以快速恢复正确配置。十二、工程升级 ESP-IDF 时的注意事项ESP-IDF 工程升级时不建议简单地复制旧工程 ↓ 修改 ESP-IDF 路径 ↓ 直接 build特别是工程目录发生变化时旧的build/ CMakeCache.txt可能保存旧路径。 推荐流程备份工程 ↓ 确认芯片型号 ↓ 确认 ESP-IDF 版本 ↓ 删除 build ↓ 重新设置 Target ↓ 重新生成 CMake ↓ 检查 sdkconfig ↓ 重新编译 ↓ 重新烧录 ↓ 检查启动日志十三、本次问题的核心结论本次 ESP32-SOLO-1 不断重启的核心问题可以归纳为ESP32-SOLO-1 │ │ 单核 ↓ 实际硬件只有 CPU0 │ × │ 工程却按照多核 ESP32 编译 │ ↓ cpu_start 尝试启动 CPU1 │ ↓ start_other_core() │ ↓ abort() │ ↓ 芯片复位 │ └────────→ 无限重启而在排查过程中又发现工程目录发生变化 ↓ build/CMakeCache.txt 保存旧路径 ↓ CMake 配置失败 ↓ SDK Configuration Editor 无法正常工作 ↓ 无法正常检查/修改工程配置因此正确的解决思路不是单纯修改某一行代码而是 先清理 CMake 缓存再确认 ESP32-SOLO-1 的 Target 和单核配置最后重新生成、编译和烧录整个工程。 对于 ESP32-SOLO-1 ESP-IDF v5.5 项目尤其需要注意 芯片实际单核能力与应用编译配置必须保持一致。
ESP32-SOLO-1 在 ESP-IDF v5.5 下启动不断重启问题分析与解决
文章来源说明本文由 ZeroOne AI 整理发布官网与 CSDN 双端同步首发原文见 www.zeroone-ai.com。一、问题现象在将原有 ESP32 工程升级到 ESP-IDF v5.5 后程序烧录成功但是 ESP32 上电后不断重启。 串口监视器可以看到类似以下日志I (388) boot: Loaded app from partition at offset 0x10000 I (388) boot: Disabling RNG early entropy source... I (398) cpu_start: Multicore appE (398) cpu_start: Running on single core variant of a chip, but app is built with multi-core support. E (401) cpu_start: Check that CONFIG_FREERTOS_UNICORE is enabled in menuconfigabort() was called at PC 0x400d27a4 on core 0随后出现Backtrace: ... start_other_core ... call_start_cpu0设备进入启动 → 异常 → abort → 重启 → 启动 → 异常 → 重启的循环。二、问题定位从日志中最重要的一句话是Running on single core variant of a chip, but app is built with multi-core support.它的含义是 当前实际运行的芯片是单核芯片但是编译出来的应用程序按照多核 ESP32 进行了编译。 本项目使用的是 ESP32-SOLO-1 ESP32-SOLO-1 属于单核 ESP32。 因此程序启动时ESP-IDF 发现实际硬件单核 编译配置双核于是启动代码尝试启动第二个 CPUstart_other_core()但是实际芯片没有第二个 CPU因此调用abort()最终导致芯片复位。 所以这次重启并不是普通的看门狗电源不稳定UDP 通讯异常内存不足应用程序死循环而是系统启动阶段的 CPU 配置不匹配。三、为什么以前版本可以正常运行本项目原来使用旧版本 ESP-IDF 时可以正常运行。 升级到ESP-IDF v5.5之后出现问题。 这说明需要重点检查 ESP-IDF 升级以后工程配置是否发生变化。 尤其是sdkconfig build/ CMakeCache.txt ESP-IDF Target FreeRTOS CPU 配置这些配置并不是简单地替换 ESP-IDF 目录就可以保证完全一致。四、首先确认 ESP32 TargetESP32-SOLO-1 使用的 ESP-IDF Target 仍然是esp32这里容易产生误解。 ESP32-SOLO-1 虽然是单核但是它不是esp32c3也不是esp32s2因此工程 Target 应该仍然是CONFIG_IDF_TARGETesp32可以使用idf.py show-target检查当前工程。 如果 Target 配置异常可以重新设置idf.py set-target esp32五、为什么 menuconfig 中找不到 CONFIG_FREERTOS_UNICORE这是本次问题排查中比较容易困惑的一点。 日志明确提示Check that CONFIG_FREERTOS_UNICORE is enabled in menuconfig但是在 ESP-IDF v5.5 的 SDK Configuration Editor 中却找不到Run FreeRTOS only on first core也就是CONFIG_FREERTOS_UNICORE这时候不能简单认为“找不到配置项就是没有问题”。 需要首先确认 当前 menuconfig 是否正常加载了这个工程。 因为本项目同时出现了 CMakeCache 错误。六、真正影响 menuconfig 的 CMakeCache 错误升级/复制工程以后出现了如下错误CMake Error: The current CMakeCache.txt directory E:/ESP32/Work/softAP-fixport9999/build/CMakeCache.txt is different than the directory e:/ESP32/Work/softAP/build where CMakeCache.txt was created.随后又出现The source E:/ESP32/Work/softAP-fixport9999/CMakeLists.txt does not match the source E:/ESP32/Work/softAP/CMakeLists.txt used to generate cache.这个问题非常关键。 原来的工程目录是E:/ESP32/Work/softAP后来工程变成E:/ESP32/Work/softAP-fixport9999但是build/CMakeCache.txt仍然保存着旧工程路径。 因此 CMake 发现旧工程 E:/ESP32/Work/softAP当前工程 E:/ESP32/Work/softAP-fixport9999两者不一致于是拒绝继续配置。 最终导致SDK Configuration Editor也无法正常运行。 因此在检查 CONFIG_FREERTOS_UNICORE 之前必须先解决 CMake 工程缓存问题。七、正确清理工程最简单可靠的方法是删除当前工程的build/例如E:\ESP32\Work\softAP-fixport9999\build删除整个 build 目录。 也可以执行idf.py fullclean但是如果工程目录已经发生过变化直接删除 build 往往更加可靠。 然后重新配置idf.py reconfigure再重新编译idf.py build最后烧录idf.py flash八、推荐的完整操作流程对于本项目建议按照下面顺序操作。 1. 进入正确工程目录cd E:\ESP32\Work\softAP-fixport99992. 删除旧的 build 删除build/3. 确认 Targetidf.py show-target确保esp32如果不是idf.py set-target esp324. 重新生成 CMakeidf.py reconfigure5. 打开配置界面idf.py menuconfig此时再检查 FreeRTOS 相关配置。 6. 重新编译idf.py build7. 烧录idf.py flash8. 查看启动日志idf.py monitor九、不要直接修改应用代码解决这个问题这个问题发生在cpu_start阶段。 也就是说程序甚至还没有真正进入正常的应用逻辑。 因此下面这些代码通常不是解决方案while(1)或者vTaskDelay()也不是 UDP、Wi-Fi、TCP、GPIO 等应用代码导致的。 正确的解决方向应该是芯片型号 ↓ ESP-IDF Target ↓ sdkconfig ↓ FreeRTOS CPU 配置 ↓ 重新生成 CMake ↓ 重新编译 ↓ 重新烧录十、如何判断问题是否已经解决解决以后启动日志不应该再出现Running on single core variant of a chip, but app is built with multi-core support.也不应该再出现start_other_core以及abort() was called正常情况下应该继续进入应用程序初始化例如app_main()以及项目自己的WiFi init UDP init GPIO init ...十一、建议保留一份稳定配置由于这个项目以前在旧版 ESP-IDF 下运行正常而升级 ESP-IDF 后出现配置问题后续建议将关键配置明确保存。 可以在工程中维护sdkconfig.defaults并记录ESP-IDF版本 芯片型号 Target FreeRTOS配置 Flash配置 Partition Table Wi-Fi配置例如ESP32-SOLO-1 Target: esp32 ESP-IDF: v5.5这样以后更换电脑、复制工程或者升级 ESP-IDF 时可以快速恢复正确配置。十二、工程升级 ESP-IDF 时的注意事项ESP-IDF 工程升级时不建议简单地复制旧工程 ↓ 修改 ESP-IDF 路径 ↓ 直接 build特别是工程目录发生变化时旧的build/ CMakeCache.txt可能保存旧路径。 推荐流程备份工程 ↓ 确认芯片型号 ↓ 确认 ESP-IDF 版本 ↓ 删除 build ↓ 重新设置 Target ↓ 重新生成 CMake ↓ 检查 sdkconfig ↓ 重新编译 ↓ 重新烧录 ↓ 检查启动日志十三、本次问题的核心结论本次 ESP32-SOLO-1 不断重启的核心问题可以归纳为ESP32-SOLO-1 │ │ 单核 ↓ 实际硬件只有 CPU0 │ × │ 工程却按照多核 ESP32 编译 │ ↓ cpu_start 尝试启动 CPU1 │ ↓ start_other_core() │ ↓ abort() │ ↓ 芯片复位 │ └────────→ 无限重启而在排查过程中又发现工程目录发生变化 ↓ build/CMakeCache.txt 保存旧路径 ↓ CMake 配置失败 ↓ SDK Configuration Editor 无法正常工作 ↓ 无法正常检查/修改工程配置因此正确的解决思路不是单纯修改某一行代码而是 先清理 CMake 缓存再确认 ESP32-SOLO-1 的 Target 和单核配置最后重新生成、编译和烧录整个工程。 对于 ESP32-SOLO-1 ESP-IDF v5.5 项目尤其需要注意 芯片实际单核能力与应用编译配置必须保持一致。