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.