This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

QSPI Peripheral Latency Explanation

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.

Parents Reply
  • 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. 

Children
No Data
Related