nRF54L15 sQSPI intermittently reports successful short RX transactions with all-0xFF data

Question

I am developing a custom nRF54L15 board using a GigaDevice GD5F1GQ5REYIGR SPI NAND connected through the nRF54L15 sQSPI/MSPI interface. 
 I have encountered a highly reproducible issue where mspi_transceive() reports successful completion, but the receive buffer intermittently contains only 0xFF . 
 The problem can also occur during NAND identification at startup. 
 Environment 
 
 nRF Connect SDK: v3.3.1 
 sdk-nrf commit: 1d7a0b0e49... 
 sdk-zephyr: ncs-v3.3.1 , commit 37e6c285... 
 sdk-nrfxlib: v3.3.1, commit 632dc0afa... 
 sQSPI library/FLPR firmware: v1.2.1 
 MCU: nRF54L15 
 NAND: GD5F1GQ5REYIGR 
 Nominal sQSPI frequency: 8 MHz 
 
 The reproduction is a standalone application. BLE, filesystem activity and runtime device PM are not involved. 
 Symptom 
 A legal GET FEATURE transaction is issued as: 
 0x0F command 0xC0 8-bit address 4-byte RX 
 The API reports success for both successful and failed transactions. 
 Successful reads return repeated legal NAND status values such as: 
 00 00 00 00 
 or, when genuinely busy: 
 01 01 01 01 
 Failed reads return exactly: 
 FF FF FF FF 
 There are no partially corrupted words, shifted responses, stale buffer patterns or MSPI API errors. 
 Reproduction results 
 Two baseline runs using separate MSPI calls produced: 
 
 5,175 / 8,192 failures — 63.2% 
 5,465 / 8,192 failures — 66.7% 
 
 Increasing inter-transaction spacing changes the failure probability but does not eliminate it. 
 At 1 ms spacing: 
 
 559 / 2,048 failures — 27.3% 
 820 / 2,048 failures — 40.0% 
 
 A particularly interesting result occurs when 32 reads are grouped into one mspi_transceive() call: 
 
 1,713 / 8,192 failures — 20.9% 
 2,279 / 8,192 failures — 27.8% 
 
 Within those groups, the first packets fail more frequently than later packets. 
 For example: 
 
 packet 0: approximately 35.9% failure 
 packet 1: approximately 40.6% 
 typical later packets: approximately 15–25% 
 
 This suggests that the API/configuration/transaction boundary materially affects the behaviour. 
 Startup behaviour 
 Across 12 reset attempts: 
 
 Valid NAND ID C8 41 : 9 
 Invalid FF FF : 3 
 
 Therefore the same behaviour can prevent initial NAND identification before any page read or other NAND operation takes place. 
 Things already investigated 
 The issue is not restricted to a one-byte receive. Four-byte RX transactions exhibit the same behaviour. 
 The original implementation used a packed command representation with addr_length = 0 . I understand that zero address length is documented as undefined for sQSPI. 
 The reproduction above therefore uses the legal representation with separate 8-bit command and 8-bit address phases. The failure remains. 
 The failure is also reproducible while the NAND is idle, so NAND PAGE READ busy timing does not explain it. 
 The RX path appears to perform the expected DMM preparation, cache handling, completion and release operations. 
 NCS v3.3.1 also already contains the published sQSPI v1.2.1 fixes. 
 I have not found a published Nordic issue that matches the combination of: 
 
 successful API completion; 
 all- 0xFF RX; 
 legal command/address framing; 
 strong dependence on transaction grouping; 
 strong dependence on inter-transaction delay. 
 
 Frequency observation 
 I attempted tests requesting 1, 4 and 8 MHz. 
 However, measured transaction duration remained approximately 36–38 µs in all cases. 
 A six-byte transaction at 1 MHz would itself require approximately 48 µs of wire time, so I do not believe these measurements demonstrate that the requested runtime frequency changes were actually applied. 
 I therefore do not draw any conclusion about frequency dependence from those tests. 
 Ordinary SPIM control 
 I also attempted an ordinary SPIM control test using the same physical NAND pins. 
 The SPI API calls succeeded, but READ ID returned 00 00 , so the test never reached the repeated-read stage. 
 Because these pins are the dedicated serial-memory/sQSPI group, I do not regard this result as evidence against the NAND. It 
 Questions 
 Could Nordic please clarify the following? 
 
 Can sQSPI report transfer/DMA completion before a short RX result is guaranteed to be visible in the host-accessible DMM buffer? 
 Is there a known first-transfer or configuration-to-transfer issue following nrf_sqspi_dev_cfg() ? 
 Is repeatedly configuring the sQSPI device around individual transactions supported and expected usage? 
 Is there a minimum supported/safe RX transfer size or alignment requirement beyond the currently published sQSPI limitations? 
 Are runtime sQSPI frequency changes expected to take effect without reinitialising the soft peripheral? 
 sQSPI v2.0 contains additional DPPI role-map publication/synchronisation changes. Are there any FLPR changes in v2.0 relevant to short RX transactions, transfer completion, or first-transfer behaviour that are not described in the public changelog? 
 What is Nordic's recommended transaction representation for repeatedly reading a one-byte SPI NAND feature/status register such as GET FEATURE 0x0F + address 0xC0 + one status byte ? 
 Is there an instrumented FLPR build or other Nordic-supported tracing method that could establish whether a failed transaction actually generated CS/SCK/MOSI activity and whether received data reached the FLPR/DMM path? 
 
 I can provide the standalone reproduction application, exact MSPI packet descriptors and additional retained diagnostic results if useful. 
 At present I have not accepted retries as a production workaround because the API itself reports these failed reads as successful. I would like to understand whether this is a known sQSPI limitation/defect or whether there is something incorrect in my use of the API. 
 I understand that SPI NAND devices are not currently supported by NCS as a managed flash device and that NAND-specific functions such as ECC policy, bad-block management and storage architecture are the application's responsibility. 
 This report is not requesting NAND-device support. The issue being reported is at the underlying sQSPI/MSPI transport level: mspi_transceive() reports successful completion of a valid read transaction, but the receive data intermittently remains all 0xFF . The behaviour is reproducible in a standalone application without BLE, runtime PM, filesystem, erase or program activity.