nrf_drv_qspi_write taking around 500 micro sec ( long time to write ) . Why it could be problem ?

[ARPITHA CHANDRASHEKAR]

nrf_drv_qspi_write taking around 500 micro sec ( long time to write ) . How to optimize nrf_drv_qspi_write time.?

[Amanda Hsieh]

Hi, 

How much data are you writing in nrf_drv_qspi_write()? When you called nrf_drv_qspi_init(&config, ...), what was the parameter for config.phy_if.sck_freq?

-Amanda H.

[ARPITHA CHANDRASHEKAR]

Hi,

      We are using 32 Mhz clock still getting 600 micro sec per transaction. Isnt it huge?

[Amanda Hsieh]

Hi,

Not sure about your calculations, but it is 32Mb/s * 4 = 128Mbps, so 512 bytes should take 4µs. However, that means that 600µs is even longer. 

May I know how you measure the time, and what other things your application is doing? Are you using BLE? If so the softdevice may be busy using the radio. Do you get 600µs every time or sometimes only? If only sometimes, it may suggest that the softdevice keeps the CPU busy. Do you have an event handler or a blocking call to the tx function?

-Amanda H.

[ARPITHA CHANDRASHEKAR]

Yes 32Mbits / sec * 4 = 128 MBits/sec = 128/8 Mbytes/sec = 16 Mbytes / sec. Ideally 512 bytes of transfer should take 32 micro sec. I am seeing 600 micro sec consistently. Yes we are using BLE. We have an event handler in nand_flash_init function? Which event handler are you talking about?

[ARPITHA CHANDRASHEKAR]

Are drivers API's tested with 32Mhz clock frequency ? 

[Amanda Hsieh]

Hi, 

I got the following info. form the internal:

From the hardware side, I can say that that there is some overhead for sending the WriteEnable command, checking the status register, writing the address, and then mainly the Page Program Cycle Time from the Flash memory (which can be found in the Flash memory datasheet).

 

ARPITHA CHANDRASHEKAR said:

Which event handler are you talking about?

An event handler or a blocking call to the tx function

-Amanda H.

[ARPITHA CHANDRASHEKAR]

ble_nus_data_send is it blocking call? You mean to say Internally Flash controller there is overhead in issuing write enable command  mentioned in data sheet?

[ARPITHA CHANDRASHEKAR]

How could we minimize overhead or there is anything we could do on hardware to get faster transfer?

[ARPITHA CHANDRASHEKAR]

Also if i do comment out BLE App, i am not getting any much diff in write time. It has to do with flash / CPU communication ? Is there anything we could do on hardware side to decrease overhead ? We are facing lot of issues due to write time

[ARPITHA CHANDRASHEKAR]

Is there possibility of having SPI instead of QSPI ? Will it create same set of issues.

[Amanda Hsieh]

Hi, 

You should look into the datasheet of your Flash memory and the Interface Description section of the nRF52840 PS to understand the protocol for writing to Flash via QSPI. The datasheet of their Flash memory also contains a specification for the Page Program Cycle Time, which is the longest part of a write command. For a Flash memory with 256 byte pages it takes two PP Cycle times to write 512 bytes.

ARPITHA CHANDRASHEKAR said:

Is there possibility of having SPI instead of QSPI ? Will it create same set of issues.

If the memory supports SPI, there is no problem using SPI instead of QSPI. I'm can't comment on if that would be better, as it depends on what is causing the longer time with QSPI. 

-Amanda H.