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 ? 

[jthmp]

Hi Hung,

Yes you are correct, at least on the unit I'm testing:
1. without logic analyzer attached to SPI lines the ext flash doesn't respond

2. with logic analyzer I can read back device id and other manufacturer data and I can write some data and read it back (but the data is out of sync)

This is only an issue on a small percentage of our boards (only some AT25FF321A).

I'm waiting for more defective boards to test and will post the logic analyzer results for those.

It seems like the chip might be damaged (is my guess) or that there is some slight timing difference on some of the chips which requires tweaking the firmware.

[Hung Bui]

Hi Joshua, 
I would suggest to try swapping the AT25FF321A on a defect board to a working board to see if the issue follow the AT25FF321A or the nRF52 chip.