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

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

Pertti Kasanen — Fri, 14 Feb 2020 06:32:10 GMT

No problem. It will be interesting to hear an insider opinion on how to best implement this.

I managed to write a test version for the double functionality. We need to build some test cases on top of it and test the robustness of the implementation. In an initial test, it seems to be working - tested with reading >10MB data from QSPI over USB while the other functions seemed to work as before.

The current implementation depends on FreeRTOS and is somewhat dependent on our other code framework. The basic method:

Bypass the QSPI init calls in nrfx_block_dev_qspi.c if QSPI has been already initialized from our own code
Added a function call that is called always before QSPI read/write/erase, both in our modified copy of nrfx_block_dev_qspi.c and our own QSPI access functions
The function takes a "mutex" semaphore and sets a variable marking the caller - which QSPI handler should be called when a QSPI event occurs
The QSPI event handler takes note of which event handler needs to be called, then releases the above semaphore. Makes a call to the handler that is waiting for the QSPI task completion.
Modified the block device event handler to use a fixed reference to m_active_qspi_dev instead of *p_context when in this dual-mode
The bit tricky part in the FreeRTOS context was setting the semaphores right (we have two other related semaphores in addition to the above). The same QSPI read/write functions get called both in ISR context and non-ISR. That needs some planning in the FreeRTOS setup to get it working right with "binary" type (not "mutex") semaphores.

The current implementation reads about 215000 bytes/s from USB MSC with Mac command line dd-command. That is about half of the speed I recall seeing when running as a block device only. A not too bad penalty from the added semaphores - good enough for the current need.

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

Simonr — Thu, 13 Feb 2020 14:14:05 GMT

Hi Pertti

Sorry about the delayed reply, but I had to forward this issue to our development team in hopes of a good and exact reply to your requests, as I don't know if this has been tried/done before or if it will be possible. I still haven't heard back, but I will update you as soon as I hear something. Thank you for your patience.

Best regards,

Simon

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

Pertti Kasanen — Thu, 13 Feb 2020 06:33:29 GMT

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.