BLE Sniffer triggers Task-WDT reboot + MAX_DEVICES too low (32) #234

Environment

• Board: ESP32-DIV v2
• Firmware: v1.7.2
• Chip: ESP32-S3 (QFN56) revision v0.2, 16MB flash
• Connection: CP2102 UART @ 115200 baud

Bug 1: BLE Sniffer crashes with Task-WDT reboot

Description: Entering BLE Sniffer causes the device to reboot automatically after a short period (~30-60s).

Steps to reproduce:

1. Boot device normally
2. Navigate to BLE → BLE Sniffer
3. Wait ~30-60 seconds
4. Device reboots

Crash log:

E (1010624) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (1010624) task_wdt:  - IDLE (CPU 0)
E (1010624) task_wdt: Tasks currently running:
E (1010624) task_wdt: CPU 0: nimble_host
E (1010624) task_wdt: CPU 1: IDLE
E (1010624) task_wdt: Aborting.
abort() was called at PC 0x42096f70 on core 0
Backtrace: 0x403782a2:0x3fc9a470 0x40380499:0x3fc9a490 ...

Root cause: In bluetooth.cpp, the startBLEScan() function (around line 9496) runs pBLEScan->start(kScanChunkSec, false) in a tight loop with no yield. The NimBLE host task on CPU 0 runs continuously without yielding to the IDLE task, starving the watchdog.

Proposed fix: Add vTaskDelay after each scan chunk in startBLEScan():

// In startBLEScan(), after pBLEScan->start(kScanChunkSec, false):
pBLEScan->start(kScanChunkSec, false);
vTaskDelay(20 / portTICK_PERIOD_MS);  // yield to feed watchdog

Bug 2: MAX_DEVICES too low (32)

Description: MAX_DEVICES is defined as 32 at line 8895 of bluetooth.cpp. In urban environments with dense BLE traffic, this limit is reached within seconds, causing the red "Max devices reached!" alert to appear constantly.

Proposed fix:

// bluetooth.cpp line 8895
// Before:
#define MAX_DEVICES 32
// After:
#define MAX_DEVICES 128

ESP32-S3 has 512KB SRAM, so 128 DeviceInfo structs use only a few KB — well within budget.

Additional notes

• The addApbChangeCallback(): duplicate func warning at boot (line 4431ms) is harmless and doesn't affect functionality.
• BLE Scanner showing "unknown" for most devices is normal — most BLE devices don't broadcast readable names in their advertisement data.
• Device was tested with serial monitoring at 115200 baud via CP2102.

Thank you for this great project!