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!

[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?

[Sebastian]

Hi Jorgen,

I have pc10056 v0.9.2

[Jørgen Holmefjord]

PCA10056 v0.9.2 has a Engineering A revision chip. You should get yourself a Revision 1 board, to make sure you have hardware with fixes for QSPI erratas, etc. PCA10056 v1.0.0 is the nRF52840 Development Kit, which replaces the Preview Development Kits.

[Sebastian]

Hello Jorgen,

Thanks for the answer, however the observed problem does not appear to fit any Engineering rev A chip errata. Nevertheless this is indeed an engineering lot chip so lets close the issue for the moment. I need to repeat the test with a production chip.

Thank you.