Using QSPI with DMA on nRF5340DK

Hi there,

I am currently developing on the nRF5340DK and am doing some very processor-intensive work (@ 128MHz) on data read from the QSPI bus. I would like to set up non-blocking transactions between the application core and the flash chip (mx25r6435f) on the DK. Ideally, I would like to set up QSPI with DMA so that data can constantly be read from QSPI while processing is being done. The spi_flash example is helpful, but I struggling to find a Zephyr way to interact with the flash chip asynchronously. I also cannot find any examples that use DMA.

One thing I have considered is that I am thinking about this all wrong and it's best to just use the nrfx drivers directly (like here, here, and here) to set up EasyDMA and QSPI from there like I would on the NRF52, rather than using any Zephyr APIs and DTS.

Setup:

Windows 10 21H2

VSCode 1.69.1

nRF Connect for VS Code Extension v2022.7.242

nRF Connect SDK version v2.0.0

nRF5340DK PCA10095 2.0.0 2021.42

Thank you for your help.

More info on what I have looked into:

One thing I am a bit confused about, described in the Zephyr Device Driver Model, is that the underlying implementations are likely interrupt-based while the API is synchronous. Would this allow me to implement the QSPI transactions on a separate thread from the processing that's being done so that I can still call the blocking API (in this case the flash API), without incurring large time penalties (such as polling or interrupting on every byte)? Everything is quite abstracted away so I am having a difficult time finding the underlying implementations to understand what is going on. I can see that the uses the nrfx_qspi driver which supports a interrupt-based version (though without specifying how to setup up interrupt-mode), but looking at the source I cannot tell what the "task" triggered does.

My main goal is just to avoid the app core being tied up with interrupts or polls. The network core is going to be handling the HCI Bluetooth stack, along with a couple other minor things. However, if it's possible to also have that core handle the QSPI reads somehow without overwhelming the net core then I am open to that solution.

I also feel as though I could have missed something completely obvious along the way, so please point out anything obvious that you think I may have missed.

Thanks!

  • Hi,

    I would have tried excatly the same as you do. First try to place the syncrhonous api in it's own thread, and see if that is sufficient, or if you need to use the nrfx drivers directly. In any case all transacation should be using DMA (we call it EasyDMA) on the lower abstractions layers for all peripherals, with interrupts only occuring when a transacation is finished. I don't see any reason why you can't implement either of your two suggestions.

    Best regards,
    Kenneth

  • Hi Kenneth,

    Thanks for the reply and extra information. I was able to get the flash driver integrated into its own synchronous thread and the setup overhead is sufficiently low while allowing my processing thread to operate while the transactions were taking place provided that my thread priorities are setup correctly.

    Thanks for your help!

Related