ThinkNode M6: external QSPI flash (MX25R1635F) fails to init (nrfx_qspi_init timeout 0xBAD0007)

[benskigomez]

Summary

On the Elecrow ThinkNode M6 (nRF52840 + MX25R1635F QSPI flash), the external QSPI flash never initializes with MeshCore's CustomLFS_QSPIFlash driver. nrfx_qspi_init() returns NRFX_ERROR_TIMEOUT (0xBAD0007) while waiting for the QSPI peripheral to activate.

Serial output from a companion build:

Starting QSPI initialization...
QSPI init failed: 0xBAD0007

Impact

• The M6 falls back without external flash, so contacts/channels (which DataStore routes to the "extra" FS) cannot persist to the 2MB chip.
• The failed init also used to break BLE entirely, because the aborted nrfx_qspi_init() leaves the QSPI peripheral + QSPI_IRQn enabled and poisons the SoftDevice enable. That BLE symptom is ThinkNode M6 Companion (Bluetooth): node never advertises BLE on any version (v1.13.0–v1.16.0); USB bootloader healthy, hardware confirmed good on Meshtastic #2827, fixed by companion_radio: tear down QSPI peripheral when its init fails (fixes #2827) #2828 (teardown on failure). This issue tracks the remaining root cause: the QSPI flash itself not initializing.

Notes / comparison

• The board config matches Meshtastic's M6 variant exactly: QSPI pins (SCK 32+3, CS 23, IO0 32+1, IO1 32+2, IO2 32+4, IO3 32+5), flash power enable on pin 21 driven high, and MX25R1635F (JEDEC C2 28 15, which is present in the driver's chip database).
• Meshtastic runs the same external flash successfully on the same hardware using Adafruit_SPIFlash / Adafruit_FlashTransport_QSPI, which suggests the issue is in the custom QSPI driver's peripheral bring-up rather than the board wiring.
• The timeout is at the peripheral TASKS_ACTIVATE → EVENTS_READY step inside nrfx_qspi_init(), before any flash command is issued.

Workaround

Building the M6 companion BLE role with internal flash (-D EXTRAFS instead of -D QSPIFLASH=1) gives reliable persistent storage today, at reduced capacity.

Hardware

• Device: Elecrow ThinkNode M6 (nRF52840, SX1262, MX25R1635F)
• Confirmed on companion BLE and USB builds.

[benskigomez]

Update: this is a hardware bring-up problem, not a driver bug.

I have an M6 and ran a series of standalone probes (no mesh stack — just the board variant + a flash test sketch) to characterize the QSPI flash failure. Summary: the external flash never responds, and it's reproducible with a known-good driver.

Tests and results (all reading the JEDEC ID, expecting C2 28 15 for the MX25R1635F):

1. Adafruit's Adafruit_SPIFlash driver (the same QSPI driver Meshtastic uses) → reads FF FF FF. So this isn't specific to MeshCore's CustomLFS_QSPIFlash; even the mature driver can't reach the chip. Note it does not hang the way MeshCore's nrfx_qspi_init() does (0xBAD0007 timeout) — Adafruit activates QSPI fine but the flash is simply silent.
2. Power-enable pin sweep — QSPI_FLASH_EN (P0.21) and PIN_PWR_EN (P0.27) in all four HIGH/LOW combinations → all FF FF FF.
3. Extended power-up settle (1 s) → FF FF FF.
4. Release-from-deep-power-down (0xAB) + software reset (0x66/0x99) then read → FF FF FF.
5. Brute-force scan — every GPIO (P0.02–P1.15) driven HIGH and LOW individually, reading JEDEC after each → nothing but FF FF FF; no single GPIO gates the flash.

QSPI pins used (from the variant): SCK=P1.03 (35), CS=P0.23 (23), IO0=P1.01 (33), IO1=P1.02 (34), IO2=P1.04 (36), IO3=P1.05 (37) — identical to the Elecrow/Meshtastic variant.

A constant FF FF FF (MISO idling high, never pulled low) means the chip isn't responding on these pins at all. Since power-enable pins, timing, and a DPD/reset wake all make no difference, the likely explanations are that the flash sits on a power rail/enable not reachable from these GPIOs, or it isn't wired to the assumed QSPI pins (these pin numbers appear to be inherited from a port where the external flash may never have been exercised).

Ask: could Elecrow or anyone with the M6 schematic confirm (a) how the MX25R1635F is powered (which rail / enable line, and polarity) and (b) the actual QSPI pin mapping? I'm happy to flash test builds and report results — I can verify any proposed wiring in a few minutes.

In the meantime, building the companion firmware with -D EXTRAFS instead of -D QSPIFLASH=1 gives reliable persistent storage in internal flash as a workaround.

[oltaco]

Thanks for your work on this, looks like you're already far down the rabbit hole 👍

I wonder if it is possible that it's a faulty flash chip on your hardware?

[benskigomez]

That is entirely possible and is constantly stuck in the back of my mind. I have contacted Elelcrow and asked about some additional info.

[oltaco]

The only reason I question it is that nobody else has brought this up before and I'm sure people would have tested the companion firmware on ThinkNode M6 before.

[benskigomez]

I agree. I second guessed it for days, but I have found several users that have reported that BLE was an issue after flashing the BLE companion (maybe a bad batch of chips). Most of which have reported as flashing to Meshtastic out of frustration. I kinda hope that it is a faulty chip.

[benskigomez]

I just confirmed on 2 additional M6 units that the external flash is failing to start up. On Meshtastic this fails silently and the BLE radio starts. On Meshcore this failure prevents the BLE radio from starting. Regardless, the external flash is not accessed and all storage takes place on the internal memory.

[benskigomez]

Resolved — the hardware does not have the flash populated. Elecrow has confirmed that the ThinkNode M6 ships without the external QSPI flash installed — the MX25R1635F footprint is DNP (not populated). This matches the earlier findings on this issue: the SOP-8 pad is empty in photos, and reading the JEDEC ID returns 0xFF/0xFF/0xFF.

So the nrfx_qspi_init timeout (0xBAD0007) is expected: there is no chip on the QSPI bus to respond. It is a hardware population fact, not a firmware bug.

Workaround / what to run on the M6: use internal flash for persistence (the nrf52840_s140_v6_extrafs ldscript / ExtraFS) instead of QSPI. Firmware simply should not assume an external QSPI flash is present on this board. (Related: #2828 tears the QSPI peripheral down cleanly when its init fails, which also prevents it from interfering with the SoftDevice/BLE bring-up — see #2827.)

Closing as resolved (external flash not populated on the M6).