Use nrfx QSPI with Zephyr filesystem

[CktDesigner]

I'm using Zephyr on a nRF52840 and I'd like to use the QSPI with the Fat Filesystem.   I added the following Config statements to prj.conf:

# Filesystem
CONFIG_FILE_SYSTEM=y
CONFIG_FAT_FILESYSTEM_ELM=y
CONFIG_NRFX_QSPI=y
CONFIG_DISK_ACCESS=y
CONFIG_DISK_ACCESS_SDHC=y
CONFIG_DISK_ACCESS_SPI_SDHC=y

The nrfx QSPI driver and file system code is then included in the build, but I'm unsure how to associate the QSPI with the filesystem.    I don't see a "CONFIG_DISK_ACCESS_QSPI_SDHC" to replace the "CONFIG_DISK_ACCESS_SPI_SDHC".    Or is there a different way to do this that I'm missing?

Thanks!

[Simon]

Sorry for the delay on this. Have you made any progress lately? I'll look into your issue today/tomorrow.

[CktDesigner]

Hi Simon,

Yes, I was able to get a better understanding of what was happening via the Zephyr/Slack group.   I was trying to control the configuration via CONFIG statements.   I guess I didn't understand that most of the configuration is done via device-tree (via okay/disabled status, or other parameter modifications) overlay files.   My case was more confusing in that I want to use the non-blocking feature of TWIM so that most I2C activities are performed in the background.   The "stock" I2C/Nordic driver in Zephyr doesn't expose the interrupt handler (which I need to catch the completion signal/interrupt and start the next job in the queue).   So I had to disable the TWIM instance via device-tree, but enable it via CONFIG, since when enabling via device-tree, the internal interrupt is connected via "IRQ_CONNECT" (and I need to do that in my code to handle the interrupt myself).  If IRQ_CONNECT is called in both places, I get the error mentioned above.   This sort of goes against the device-tree guidance.   Evidently the device-tree methodology is replacing the CONFIG methodology, but for now both appear to be in place, so it is a bit confusing.

Now that I more fully understand device-tree, I see its value in making things "more convenient" and perhaps making it easier to keep things consistent over multiple vendor devices.  But it also "hides" a lot of things that historically have been more visible in user code.   (I have always put "config" calls as the first things in my code.  So it would be very easy to determine what was being configured by glancing at the beginning of the code.   Now most of that work is hidden (for better or worse) in initialization code (or MACROS) inside the driver code.)  I guess I have to "get with the times"!!

Thanks very much for your help!

[Simon]

I'm happy you got help and was able to get past the error.

However, I'm handling another case regarding this. I talked to a colleague and got some more insight on this topic (File System on external flash in NCS), check it out here: https://devzone.nordicsemi.com/f/nordic-q-a/72045/flash-filing-system-for-nrf-connect-sdk

Sorry for not providing this information at an earlier point, but I wasn't aware of this before now.

Best regards,

Simon

[CktDesigner]

After doing a lot of reading, I determined that it is not possible to control an SDcard using QSPI.   While they are very similar, QSPI transmits command over the D0 signal while SDcard uses a separate CMD signal (for both command and response).   I thought that perhaps there might be a way to connect D0 to CMD, but I don't see a way to retrieve the command response using the QSPI setup.

[Simon]

It does not seem like it's possible to use QSPI with an SD Card, after browsing through DevZone. I'll copy in another answer I found:

"Using SD card in any other modes than SPI would require a licence from the SD card association, link. Even if we had such an example, we wouldn't be allowed to publish it. Hence only SPI examples are shown for SD Cards."

Would using SPI be an option for you?

Best regards,

Simon