Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Accessing QSPI flash simultaneously in nRF52840 program and as a USB block device

Has anyone (tried to) simultaneously use the same QSPI Flash memory directly from an nRF52840 program and as a USB block device?

We have both functions running in the same hardware when used alternatively: can either read/write the QSPI memory with nrf_drv_qspi_init(), nrfx_qspi_read() and nrfx_qspi_write or disable that and use the same memory as a USB MSC block device with NRF_BLOCK_DEV_QSPI_DEFINE(), etc.

I'm trying to figure out if it is worth the effort to try to combine these. Probably should

  • Let the block device library initialize the QSPI and the flash memory
  • Starting read/write operations (externally to the block device) could be quite simple - may need to fetch come pointer from inside the block device library
  • Should add a flag showing if a read/write is from "our app" or "block device", modify the QSPI event handler to pass the read/write results accordingly either to the block device library or to our own code.

I suppose this is not possible without modifying the block device library code? But the modifications needed might be reasonably small?

Setup: nRF52840 on our own board, MX25R6435F, SDK16.0, SoftDevice 7.0.1, FreeRTOS.

Pertti

Parents
  • This functionality could have been relatively easy to add if the QSPI handler would get a pointer to the RAM address used in the operation that completed. We could just check from the buffer used what type of event handling is required. But the event handler does not even know wast it a read, write or erase operation that completed.

    Is it possible to read that information directly from the QSPI peripheral registers: would the registers READ.DST and WRITE.SRC of QSPI be always valid at the time of the competition handler call? Or would it require some mutex that prevents another QSPI command from being issued before the event handling completes?

    Is it possible to read from the QSPI registers the type of the operation (a read, write or erase) that completed? The SDK block device code seems to keep track of that in it's on structs.

Reply
  • This functionality could have been relatively easy to add if the QSPI handler would get a pointer to the RAM address used in the operation that completed. We could just check from the buffer used what type of event handling is required. But the event handler does not even know wast it a read, write or erase operation that completed.

    Is it possible to read that information directly from the QSPI peripheral registers: would the registers READ.DST and WRITE.SRC of QSPI be always valid at the time of the competition handler call? Or would it require some mutex that prevents another QSPI command from being issued before the event handling completes?

    Is it possible to read from the QSPI registers the type of the operation (a read, write or erase) that completed? The SDK block device code seems to keep track of that in it's on structs.

Children
No Data
Related