nrf_drv_qspi_write taking around 500 micro sec ( long time to write ) . How to optimize nrf_drv_qspi_write time.?
nrf_drv_qspi_write taking around 500 micro sec ( long time to write ) . How to optimize nrf_drv_qspi_write time.?
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.
Hi,
We are using 32 Mhz clock still getting 600 micro sec per transaction. Isnt it huge?
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.
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?
How could we minimize overhead or there is anything we could do on hardware to get faster transfer?
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
Is there possibility of having SPI instead of QSPI ? Will it create same set of issues.
Is there possibility of having SPI instead of QSPI ? Will it create same set of issues.
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.
Ok. I will check. I wanted to ask another question. Is there any additional easy_dma API's for QSPI in Nordic platform ? If so, could you please post the link if easy_dma feature for QSPI can be implemented?
QSPI — Quad serial peripheral interface has EasyDMA. There isn't any configuration needed for EasyDMA in the QSPI peripheral as the QSPI peripheral automatically takes care of splitting DMA transfers into the page writes. See this post.
-Amanda H.