fix(nrf52): keep BLE active during reset cleanup - #10873
Merged
thebentern merged 1 commit intoJul 3, 2026
Merged
Conversation
Contributor
⚡ Try this PR in the Web FlasherNote Building this pull request… the flash button, badges and supported-board |
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThree source files reorder operations so ChangesReset/Bluetooth Ordering Fix
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant Module as AdminModule / MenuHandler / SystemCommandsModule
participant NodeDB
participant Bluetooth
User->>Module: Trigger factory/node reset
Module->>NodeDB: factoryReset() / resetNodes()
NodeDB-->>Module: Reset complete
Module->>Bluetooth: disableBluetooth()
Module->>Module: Schedule reboot
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
3 tasks
Contributor
Firmware Size Report22 targets | vs
Show 17 more target(s)
Updated for fa3b1a1 |
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Aug 31, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jk-aibot
pushed a commit
to jk-aibot/firmware
that referenced
this pull request
Sep 1, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jk-aibot
pushed a commit
to jk-aibot/firmware
that referenced
this pull request
Sep 3, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jk-aibot
pushed a commit
to jk-aibot/firmware
that referenced
this pull request
Sep 3, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
Itzdavid01
pushed a commit
to Itzdavid01/firmware
that referenced
this pull request
Sep 5, 2026
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
jeremiah-k
added a commit
to jeremiah-k/meshtastic-firmware
that referenced
this pull request
Sep 6, 2026
Sending AdminMessage.factory_reset_device to a TBeam over USB serial ends in 'Guru Meditation Error: Core 0 panic'ed (LoadProhibited)' inside npl_freertos_eventq_remove, the NimBLE FreeRTOS port event-queue layer, followed by a slow crash-reboot. Defaults do get applied, but the panic beats the admin ACK and wedges clients. Root cause: the reset ordering ran the destructive work while the BLE stack was still live. nodeDB->factoryReset(true) calls nvs_flash_erase() (NodeDB.cpp:874) while the NimBLE host task, its host-timer callout and the NVS-backed bond store (ble_store_config, the 'nimble_bond' namespace; see NimbleBluetooth::purgeIncompatibleBleBonds) are all running. Only then does disableBluetooth() tear the stack down (NimbleBluetooth::deinit -> BLEDevice::deinit -> nimble_port_stop/nimble_port_deinit), and the teardown dereferences host state invalidated by the erase under it, panicking in npl_freertos_eventq_remove. meshtastic#10873 moved disableBluetooth() after the reset cleanup for nRF52's sake (the nRF52840 warm-node raw- flash erase needs the SoftDevice alive); on ESP32 that ordering is exactly backwards. Fix: on ESP32 call disableBluetooth() before nodeDB->factoryReset() / factoryReset(true) so nvs_flash_erase() runs against a quiesced stack; nRF52 keeps the meshtastic#10873 ordering (BLE stays active during its flash cleanup and is disabled after). disableBluetooth() self-guards on HAS_BLUETOOTH, so BLE-less ESP32 builds are unaffected. Applied to the admin factory_reset_config and factory_reset_device handlers and to the INPUT_BROKER_FACTORY_RST path in SystemCommandsModule, which shares the same nvs_flash_erase hazard. MenuHandler's node-db reset only clears the in-RAM/file node list and keeps the safe post-reset order. Build check: pio run -e tbeam SUCCESS.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #10851.
nRF52 factory/config reset paths were stopping Bluetooth before running reset cleanup. On current firmware that cleanup can perform flash-backed work before scheduling reboot, including the nRF52840 warm-node raw-flash erase added in #10705. Keeping BLE/SoftDevice active until after the reset cleanup lets those flash operations complete normally, then advertising is stopped immediately before the scheduled reboot.
This moves
disableBluetooth()after the reset cleanup for:Hardware repro / verification
Bench target: Muzi Base nRF52840 on
/dev/cu.usbmodem31201,MUZI_BASE, firmware2.8.0.84b1af0.Before fix, on upstream
develop:bluetooth.enabled=falsefollowed by admin reboot: PASS, metadata returned immediately.meshtastic --factory-reset: FAIL, serial API timed out repeatedly for more than two minutes. USB stayed enumerated, but Meshtastic metadata never returned until bootloader/PlatformIO recovery.Power::reboot()usesNVIC_SystemReset()inv2.7.22.96dd647,v2.7.26.54e0d8d, and currentdevelop; nosd_nvic_SystemReset()change exists in that path.After fix, final artifact flashed to the same Muzi Base:
meshtastic --factory-reset: PASS. Poll 1 saw expected USB disconnect during reboot; poll 2 returned metadata successfully with no recovery.bluetooth.enabled=True,lora.region=13, metadata healthy.Tests
trunk fmt src/modules/AdminModule.cpp src/modules/SystemCommandsModule.cpp src/graphics/draw/MenuHandler.cppgit diff --checkpio run -e muzi-basepio run -e muzi-base -t upload --upload-port /dev/cu.usbmodem31201Native test note:
./bin/run-tests.shdoes not run on this macOS checkout because it uses GNU/bash features not available here (mapfile,find -printf).python -m platformio test -e nativefails before tests on existing unrelated native compile errors insrc/graphics/draw/NotificationRenderer.cppvariable-length array initializers and Linux input headers.Summary by CodeRabbit