ESP32-SOLO-1 在 ESP-IDF v5.5 下启动不断重启问题分析与解决

一、问题现象

在将原有 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 app

E (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 menuconfig

abort() 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 发现：

实际硬件：单核
编译配置：双核

于是启动代码尝试启动第二个 CPU：

start_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 Target

ESP32-SOLO-1 使用的 ESP-IDF Target 仍然是：

esp32

这里容易产生误解。
ESP32-SOLO-1 虽然是单核，但是它不是：

esp32c3

也不是：

esp32s2

因此工程 Target 应该仍然是：

CONFIG_IDF_TARGET="esp32"

可以使用：

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-fixport9999

2. 删除旧的 build
   删除：

build/

3. 确认 Target

idf.py show-target

确保：

esp32

如果不是：

idf.py set-target esp32

4. 重新生成 CMake

idf.py reconfigure

5. 打开配置界面

idf.py menuconfig

此时再检查 FreeRTOS 相关配置。
6. 重新编译

idf.py build

7. 烧录

idf.py flash

8. 查看启动日志

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 项目，尤其需要注意 芯片实际单核能力与应用编译配置必须保持一致。