QSPI Peripheral Latency Explanation

RE: QSPI Peripheral Latency Explanation

Sebastian — Tue, 14 Aug 2018 07:17:57 GMT

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.

RE: QSPI Peripheral Latency Explanation

Jørgen Holmefjord — Tue, 14 Aug 2018 07:06:21 GMT

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.

RE: QSPI Peripheral Latency Explanation

Sebastian — Wed, 08 Aug 2018 04:45:21 GMT

Hi Jorgen,

I have pc10056 v0.9.2

RE: QSPI Peripheral Latency Explanation

Jørgen Holmefjord — Tue, 07 Aug 2018 12:35:47 GMT

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?

RE: QSPI Peripheral Latency Explanation

Sebastian — Tue, 07 Aug 2018 10:24:50 GMT

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.

RE: QSPI Peripheral Latency Explanation

Jørgen Holmefjord — Mon, 06 Aug 2018 12:53:36 GMT

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.

RE: QSPI Peripheral Latency Explanation

Sebastian — Sat, 04 Aug 2018 14:56:48 GMT

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.

RE: QSPI Peripheral Latency Explanation

Sebastian — Fri, 03 Aug 2018 13:08:15 GMT

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

RE: QSPI Peripheral Latency Explanation

Jørgen Holmefjord — Fri, 03 Aug 2018 12:56:09 GMT

Thank you for the update.

Scope captures would be helpful!

RE: QSPI Peripheral Latency Explanation

Sebastian — Fri, 03 Aug 2018 12:50:12 GMT

Hello Jorgen

Thanks for coming back.

No the CS goes high after the transfer finishes and this is the strange thing.

The latency delay is fixed at 4.3usec for blocking mode and at about 6usec when the event handler is used.

I can provide oscilloscope captures if you'd like.

RE: QSPI Peripheral Latency Explanation

Jørgen Holmefjord — Fri, 03 Aug 2018 12:42:11 GMT

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