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. 

[Jørgen Holmefjord]

The read operation is not completed until the READY event is generated by the QSPI peripheral. I do not have the exact details on what the peripheral is doing in the ~2.5 µs from CSN line goes low until the event is generated, but most likely there is still some DMA operations ongoing etc. After that the time is spent in the code on context switching, GPIO control, and to start the next read operation.

I checked the code with some GPIO debugging:

0 is set high before read function is called, and set low after event is received.

1 shows the time spent inside read function (nrfx_qspi_read)

2 is set high before WAIT_FOR_PERIPHERAL macro is entered, and set low after.

3 shows the CSN line of QSPI peripheral. 

In my test, there is 0.9 µs from event is received until next time read function is called.

[Sebastian]

Hello Jorgen,

Sorry for the late reply. The timescale of the whole tranasaction seems too long. How many bytes are you transferring and at what speed?

Can you do a transaction with 64 bytes only and 32MHz clock rate for the QSPI clock?

Unfortunately, I am out of office and cannot send further scope captures but the one I uploaded was as i describe above.

Thank you. 

[Jørgen Holmefjord]

Sorry, my capture was with default 256 bytes and 2 MHz, this one is with 64 bytes and 32 MHz. As you can see, only the total duration of the transfer is decreased, not the duration of the driver/example functions.

 

Which version of the DK are you using?