1，SDK版本：ESP-IDF v4.3-beta3-dirty 2，硬件：ESP32双核，8M Flash模块。 3，业务逻辑概况：用ESP32做蓝牙网关，使用BT客户端+WIFI，获取蓝牙传感器数据并上传服务器，必须长期在线！ 4，问题描述： 当WIFI信标超时后，始终重连接不成功，不得已，在30秒后依然连接不上情况下，使用esp32_restart()重启,然后就可以连接WIFI成功了，这个问题不知何故，姑且就这样解决。 但是当长期运行（大约10*24小时后），遇到WIFI信标超时后，使用esp32_restart()重启却无效了！！但是也没有PANIC，业务逻辑照样正常！这样的结果就是...

@ESP_Gargamel 重新上电后就好了。 重新上电后日志： rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:6968 load:0x40078000,len:14292 load:0x40080400,len:3688 entry 0x40080678...

用的release. v4.3最新版本 WIFI掉线后重新连接，始终不成功！！蓝牙也扫描不到设备了！！！ 日志如下。 [0;33mW (09:42:52.599) BOBO_CONNECT: Wi-Fi disconnected,retry to connect to the AP,restart 1,[0m W (58557027) wifi:m f probe req l=0 W (58557268) wifi:m f probe req l=0 W (58557511) wifi:m f probe req l=0 W (58557753) wifi:m f probe req l=0 ...

ok!! will try it!

用的是V4.3

我实际用的应该是V4.3.

我的克隆如截图：

多谢回复！！ “1、你还是把发生 task WDT 和 crash 时的 backtrace 解析一下，可以获取一些 BTC task 内的情况，看为何 CPU0 都被这个 task 占用了，这个可能还需要内部蓝牙的同事看一下；” 是的，需要你们蓝牙的专家看下，为何BTC控制器这个任务会触发WDT？尽管只是作广播？是不是这个BTC协议栈有测试不很充分？？ “2、你现在 task WDT 的时间设置多大？能否设大一些做下测试？” 默认的5秒WDT 超时，按照手册，IDLE有存储回收功能，如果设置太长会不会影响到API系统稳定？？我看IDF 源代码，大量使用动态存储分配释放。如果IDLE超时太长，...

“能否解析一下 crash 时候 backtrace？看一下 call stack。”，我感觉是BTC任务狗触发，既然高优先级的BTC都触发，那么IDLE0和IDLE1触发显然是必然的。问题是，为何没有什么操作的BTC WDT会触发？ 当时运行的BTC任务只是BLE广播状态而已。

此外，我的业务逻辑调用分区写备份数据，分区写/擦除会不会太占用时间，导致BTC有时没法及时工作（即使仅仅广播？）

蓝牙始终开着，这样用户可以随时配网。我测试，连续配网，都不会出错。
另外，这样不用专门切换到配网模式，用户体验应该更好。

日志上显示，显示连续3此BTC TASK WDT触发，然后发狂，大约1秒后重启。

BT代码基于你们DEMO BLE服务器代码，增加我呢逻辑（读，写，执行写的具体动作：用写/执行写的数据作为配网SSID/PASSWORD，重新连接WIFI，成功后响应以“OK”给GATT客户端。不配网情况下，读蓝牙特征即可知道是否WIFI连接OK。只有一个特征。

因为可能用户配网后换地方了，原来AP连不上了，而又没有配置新地方的AP，于是就会WIFI断开。如果用户忘记配网，固件应该也能正常工作，就是我测测试的目的。否则用户一旦想起配网，却不能配网（蓝牙，也就是固件疯了），就是大问题了。我上一贴子日志显示，长期连不上会重启的！尽管重启时间很短，也不影响产品功能，但是是个隐患，我希望消灭所有已知隐患。