QSPI Peripheral Latency Explanation

[Sebastian]

Hello, 

I am using nRF52840 with nRF5_SDK_15.0.0_a53641a. 

I am looking at the QSPI example which I have slightly modified so that after the write of 256 bytes, it enters into a loop reading continiously 64 bytes from the external Flash.

To read 64 bytes with 32MHz clock requires about 4.4usec with the QSPI. 

My code looks like this:

while(1)
{nrfx_err=nrfx_qspi_read(m_buffer16_rx, 64, 0);
WAIT_FOR_PERIPH();
}

I am noticing an 4.5 to 6usec latency between the end of read (i.e CS goes high) till the next read cycle begins.

Any explanation about this latency? Is due to the Flash or is the MCU peripheral actually doing something in that time?

Thank you for your answers.

[Jørgen Holmefjord]

Hi,

I would expect a short delay to handle the events and start the next read operation, but it is hard to say exactly why you get this long delay. Have you tried setting some GPIOs in your application to see when the delay happens? 

Do the CSN pin stay low during this delay?

Best regards,
Jørgen

[Jørgen Holmefjord]

Thank you for the update.

Scope captures would be helpful!

[Sebastian]

Hello Jorgen,

Check above the transaction for 64 bytes @32MHz. The code that is running is the following:

while(1){
nrfx_err=nrfx_qspi_read(m_buffer16_rx, 64, 0);
WAIT_FOR_PERIPH();
}

Any comments are welcome.

Note: I am using nrf52840 dev kit, reading the on board Flash

[Sebastian]

Hi Jorgen,

Since we are discussing QSPI being you can light another aspect. 

I disconnected the flash memory on board the dev kit and the driver will not initialize the QSPI module but rather will return with NRFX_ERROR_TIMEOUT.

Can you explain what exactly is the driver trying to do during initialization that makes it timeout when the memory is disconnected?

Thank you.

EDIT: My bad I just saw it in the documentation:

'During the activation process, the internal clocks are started and the QSPI peripheral tries to read the status byte to read the busy bit. Reading the status byte is done in a simple poll and wait mechanism. If the busy bit is 1, this indicates issues with the external memory device. As a result, nrfx_qspi_initreturns NRFX_ERROR_TIMEOUT'

So at initialization the driver actually tries to read the peripheral memory. Strange thing though, I cannot see the command 0x05 being send from the MCU QSPI in order to read the memory status register. CS goes low but no clock or data on the lines when the memory is disconnected.