After mcu reset calling nrfx_qspi_init on external flash fails with NRFX_ERROR_TIMEOUT

[jthmp]

We are running a custom board with the nrf52840 mcu on the legacy 17.1 nrf sdk.
external flash IC is  AT25FF321A

On a small portion of our boards (maybe 1 - 5%) we are noticing that the external flash init code nrfx_qspi_init is failing with err = NRFX_ERROR_TIMEOUT;
This seems to happen in nrfx_qspi.c function qspi_ready_wait.

This happens when we do a mcu reset or software reset.
However, when we do a power reset (unplug the battery and plug back in) then the qspi init is a success.
We tried increasing the timeout in the qspi ready wait but that didn't work, we also tried clearing all the qspi gpio before hand but that didn't work either.
We also tried slowing down the qspi clock rate to 2 MHz (from 16MHz) but still no luck.
We also called nrfx_qspi_uninit but that failed on assert since 

NRFX_ASSERT(m_cb.state != NRFX_DRV_STATE_UNINITIALIZED

Here is a small sample of the code:

#define GPIO_SPI_MISO           6u  // SIO_6  = NVM SPI MISO input pin (QSPI = IO1)
#define GPIO_SPI_CLK            7u  // SIO_7  = NVM SPI CLK output pin
#define GPIO_SPI_MOSI           8u  // SIO_8  = NVM SPI MOSI output pin (QSPI = IO0)
#define GPIO_SPI_IO3            9u  // SIO_9  = NVM SPI IO3 pin
#define GPIO_SPI_IO2            10u // SIO_10 = NVM SPI IO2 pin
#define GPIO_SPI_CS             34u // SIO_34 = NVM SPI CS output pin

nrfx_qspi_config_t nrfx_qspi_config = {.xip_offset = NRFX_QSPI_CONFIG_XIP_OFFSET,
                                       .pins =
                                           {
                                               .sck_pin = GPIO_SPI_CLK,
                                               .csn_pin = GPIO_SPI_CS,
                                               .io0_pin = GPIO_SPI_MOSI,
                                               .io1_pin = GPIO_SPI_MISO,
                                               .io2_pin = GPIO_SPI_IO2,
                                               .io3_pin = GPIO_SPI_IO3,
                                           },
                                       .prot_if =
                                           {
                                               .readoc    = (nrf_qspi_readoc_t)NRFX_QSPI_CONFIG_READOC,
                                               .writeoc   = (nrf_qspi_writeoc_t)NRFX_QSPI_CONFIG_WRITEOC,
                                               .addrmode  = (nrf_qspi_addrmode_t)NRFX_QSPI_CONFIG_ADDRMODE,
                                               .dpmconfig = false,
                                           },
                                       .phy_if =
                                           {
                                               .sck_delay = (uint8_t)NRFX_QSPI_CONFIG_SCK_DELAY,
                                               .dpmen     = false,
                                               .spi_mode  = (nrf_qspi_spi_mode_t)NRFX_QSPI_CONFIG_MODE,
                                               .sck_freq  = (nrf_qspi_frequency_t)NRFX_QSPI_CONFIG_FREQUENCY,
                                           },
                                       .irq_priority = (uint8_t)NRFX_QSPI_CONFIG_IRQ_PRIORITY};
                                       
nrfx_err_t nrf_err = nrfx_qspi_init(&nrfx_qspi_config, m_nrfx_qspi_handler, p_context);
// nrf_err == NRFX_ERROR_TIMEOUT (13)

what is going on and is there a firmware solution?

[Hung Bui]

Hi Joshua, 
I'm suspecting that when you do a mcu reset or software reset the AT25FF321A was still in a non default state so it doesn't response to the nrfx_qspi_init as it should. 
Have you tried to add some delay before you call nrfx_qspi_init() ? 

Could you use a logic analyzer on the QSPI pins and check if there is any difference in the signal when you do a soft reset on the board with issue ? 

On the 1%-5% boards that having the issue, are you able to reproduce the issue on these board all the time ? Or it only occurs occasionally ? 

[jthmp]

Actually, we believe this is most likely a broken external flash IC issue

[Hung Bui]

Hi Joshua, 
One simple test you can do is to swap the external flash from a good board to a defect one to see if the issue follow the external flash or not. 

[jthmp]

Hi, yes it's a hardware issue. we can close the ticket

[jthmp]

Hi Hung,

So, some new info. We attached a logic analyzer to a board having the external flash issue and then ran our qspi init code and this time it worked. But when writing some data like [0,1,2,3...etc] to a portion of flash and then reading it back we get double values:
write data [0, 1, 2, 3, 4 ...]

read data [0, 0, 1, 1, 2, 2, 3, 3, ...etc]

So the external flash does response but only if we attach the logic analyzer. Is this something to do with th nrf qspi settings? We tried with the nrf 17.1 qspi example project as well and got same results.

[Hung Bui]

Hi Joshua, 

Please correct me if I'm wrong. My understanding is that when you don't have the logic analyzer connected you can not access the external flash. When you have the logic analyzer connected you can access the flash but the read data has double value ? 

And this only occurs on the defect external flash ? or it happen on all AT25FF321A you tested with ? 

Do you see any thing suspicious on the logic analyzer trace ? Could you attach the trace ?