companion_radio: tear down QSPI peripheral when its init fails (fixes #2827)#2828
Open
benskigomez wants to merge 1 commit into
Open
companion_radio: tear down QSPI peripheral when its init fails (fixes #2827)#2828benskigomez wants to merge 1 commit into
benskigomez wants to merge 1 commit into
Conversation
…eshcore-dev#2827) On nRF52 BLE companion builds, a failed external-flash init left BLE completely dead: the node never advertised on the Elecrow ThinkNode M6 on any firmware version, even though the same unit runs fine over LoRa and pairs over BLE under other firmware. Root cause: when nrfx_qspi_init() fails (the M6 returns NRFX_ERROR_TIMEOUT / 0xBAD0007 during QSPI activation), it has already enabled the QSPI peripheral and enabled QSPI_IRQn in the NVIC at priority 0 (reserved for the SoftDevice), and it does not clean any of that up before returning. The very next step, the SoftDevice enable in Bluefruit.begin(), then fails (returns false) and every later BLE call reports NRF_ERROR_SOFTDEVICE_NOT_ENABLED, so the node never advertises. USB companion builds are unaffected because they never enable the SoftDevice. Fix: on the QSPIFlash.begin() failure path, disable QSPI_IRQn and power the QSPI peripheral back down before continuing. This only runs on the failure path, so boards whose QSPI init succeeds are unaffected, and BLE now comes up cleanly even when the external flash is absent or fails to initialize. Validated on a ThinkNode M6: with the QSPI init still timing out, the SoftDevice now enables, the node advertises, and the MeshCore app pairs and exchanges frames.
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.
Problem
On nRF52 BLE companion builds, a failed external-flash init leaves BLE completely dead. The Elecrow ThinkNode M6 never advertises over BLE on any firmware version (#2827), even though the same unit runs fine over LoRa and pairs over BLE under other firmware.
Root cause
When
nrfx_qspi_init()fails (the M6 returnsNRFX_ERROR_TIMEOUT/0xBAD0007during QSPI activation), it has already enabled the QSPI peripheral and enabledQSPI_IRQnin the NVIC at priority 0 (reserved for the SoftDevice) — and cleans none of it up before returning. The next step,Bluefruit.begin()enabling the SoftDevice, then fails; every later BLE call returnsNRF_ERROR_SOFTDEVICE_NOT_ENABLED, so the node never advertises. USB companion builds are unaffected because they never enable the SoftDevice.Fix
On the
QSPIFlash.begin()failure path, disableQSPI_IRQnand power the QSPI peripheral back down before continuing. Runs only on the failure path, so boards whose QSPI init succeeds are unaffected.Validation
On a ThinkNode M6 (with the QSPI init still timing out): the SoftDevice now enables, the node advertises, and the MeshCore app pairs and exchanges frames. Confirmed via boot-stage instrumentation that the SoftDevice enable goes from failing to succeeding once the peripheral is torn down.
Notes
The underlying M6 QSPI-init timeout is a separate issue (the custom QSPI flash driver doesn't bring up the
MX25R1635F); this PR makes BLE robust to that failure rather than fixing the flash itself.