mirror of
https://github.com/meshtastic/firmware.git
synced 2026-09-28 09:17:07 -04:00
James RichandClaude Opus 5
93cdcad712
Two findings from hardware, one fixed and one not. FIXED - the readiness handshake was a race. setBluetoothEnable() brings the BLE stack up, and on ESP32 that happens BEFORE main() constructs the mesh handler. The hook at the end of NimbleBluetooth::setup() therefore ran against a null bleMeshHandler about half the time, and when it lost the coin flip the handler sat in "waiting for Bluetooth ready" forever while the stack was already up. That is exactly what a working run and a dead run looked like on the same binary, which is why this took a diagnostic build to see: BTDIAG setBluetoothEnable(1) memReleased=0 cfgEnabled=1 nimble=0x3fcd4490 active=1 nimble non-null and already active on the first call this handler ever saw. runOnce() now polls platformReady() and calls onBluetoothReady() itself, once, whenever readiness actually arrives - no ordering assumption in either direction. ESP32 reports readiness as "nimbleBluetooth is active" rather than ble_hs_synced(), because the host syncs long before setup() has registered its service; nRF52 exports a flag from NRF52Bluetooth::setup() for the same reason. The push hooks are gone. NOT FIXED - with readiness now arriving reliably, the ESP32 build boot-loops: uptime cycles 1, 2, 1, 2 every ~3s, with "BLE mesh started" as the last line before each reset. So the fault is in what readiness unblocks - most likely ble_gap_ext_disc() starting an extended scan while the PhoneAPI's connectable advertisement is up. That fits the earlier ble_gap_adv_stop rc=8 (ENOTSUP) evidence: under CONFIG_BT_NIMBLE_EXT_ADV the legacy advertising the PhoneAPI uses is not merely noisy, it does not belong in the same stack as the extended path. Porting the PhoneAPI advertisement onto ext-adv instance 0 is now looking like a prerequisite rather than a tidy-up. Not isolated further: platformReady() and startScanning() have not been separated, so the crash could be either. DO NOT flash this to a node you care about. nRF52 is unaffected by the ESP32 fault and the RAK4631 remains healthy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>