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?

[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