Use nrfx QSPI with Zephyr filesystem

RE: Use nrfx QSPI with Zephyr filesystem

Simon — Wed, 03 Mar 2021 10:43:26 GMT

I'll look into ticket 265559 soon.

RE: Use nrfx QSPI with Zephyr filesystem

CktDesigner — Tue, 02 Mar 2021 15:40:19 GMT

I was hoping for the higher throughput that SD mode would provide, but am now trying SPI mode. I'm having an issue there as well though. I submitted a separate ticket for that question (Case ID: 265559: Use SPI to interface to SDcard under Zephyr). I'm having trouble getting the SPI chip-select to work properly. (It seemed so much easier when I could call the configuration functions directly (instead of working through device-tree) :-))

Thanks!

RE: Use nrfx QSPI with Zephyr filesystem

Simon — Tue, 02 Mar 2021 09:56:58 GMT

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

RE: Use nrfx QSPI with Zephyr filesystem

CktDesigner — Mon, 01 Mar 2021 18:37:29 GMT

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.

RE: Use nrfx QSPI with Zephyr filesystem

Simon — Thu, 25 Feb 2021 16:15:28 GMT

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

RE: Use nrfx QSPI with Zephyr filesystem

CktDesigner — Thu, 25 Feb 2021 15:26:50 GMT

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!

RE: Use nrfx QSPI with Zephyr filesystem

Simon — Thu, 25 Feb 2021 11:31:18 GMT

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

RE: Use nrfx QSPI with Zephyr filesystem

CktDesigner — Mon, 22 Feb 2021 07:01:25 GMT

Simon,

I've been looking into this and thought I'd try to get the SPI mode working, then see if I can modify disk_access_spi_sdhc.c to handle QSPI.

Using one of the examples, I found that I needed to set:

CONFIG_FILE_SYSTEM=y
CONFIG_FAT_FILESYSTEM_ELM=y
CONFIG_DISK_ACCESS=y
CONFIG_DISK_ACCESS_SDHC=y
CONFIG_SPI=y
CONFIG_SPI_2=y
CONFIG_DISK_ACCESS_SPI_SD

to get the appropriate drivers to load. Since I'm already using TWIM1 (via CONFIG_NRFX_TWIM1=y) and needed to write my own handler so multiple threads can share the I2C, I use the statement:

IRQ_CONNECT(SPIM1_SPIS1_TWIM1_TWIS1_SPI1_TWI1_IRQn,6,nrfx_isr,nrfx_twim_1_irq_handler,0);

to catch the signal from the TWIM. The TWIM handler seems to be working correctly...

However, this seems to cause a conflict in the isr table. When I compile with the SPI configs, I get the error:

1> Combining ‘zephyr/isr_tables.c’
1> gen_isr_tables.py: error: multiple registrations at table_index 4 for irq 4 (0x4)
1> Existing handler 0x2ef09, new handler 0x2ef09
1> Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

Commenting out my IRQ_CONNECT call removes the error, but also removes my ability to catch the signal from TWIM1 for my handler.

I seem to remember reading (somewhere) that nRF52840 serial peripherals share index numbers leading me to think that I should be using SPI2 for the SDcard access. Do you know if the disk_access code hard codes using SPI1? Or is there some other conflict causing the problem with the isr table?

Thanks...

RE: Use nrfx QSPI with Zephyr filesystem

CktDesigner — Thu, 18 Feb 2021 21:28:36 GMT

OK, thanks.

I did find this link: https://medium.com/home-wireless/implement-littlefs-for-qspi-flash-in-zephyr-37e591f86b48

It appears to show how to use the QSPI with "littlefs" in Zephyr. I have to admit that I haven't yet mastered the "device-tree" technology of Zephyr, so I'm not sure what is really happening here. (I'm from the "old school" and am moving to Zephyr from FreeRTOS. It seems like a lot of "stuff" happens in some hidden space and I find it hard to trace where this code is "generated" and when it executes!). But I'm going to have to figure it out since, although I'm testing with nRF52480-DK, my application will be on a custom board...

So perhaps this "littlefs" example can be used to make things work in FatFs.

Thanks!

RE: Use nrfx QSPI with Zephyr filesystem

Simon — Thu, 18 Feb 2021 20:30:27 GMT

Be aware that I don't have the best knowledge about this, and I may have overlooked/misunderstood something. You may get better answers if you ask in any of the mentioned Zephyr resources.

RE: Use nrfx QSPI with Zephyr filesystem

CktDesigner — Thu, 18 Feb 2021 16:59:51 GMT

OK... I'll look into it further. Thanks for the pointers!

RE: Use nrfx QSPI with Zephyr filesystem

Simon — Thu, 18 Feb 2021 14:21:30 GMT

I looked into this, and it does not seem like there is added any support for QSPI with FAT Fs. To give you a better overview I'll provide you the call stack:

main()-->disk_access_init() | zephyr\samples\subsys\fs\fat_fs\src\main.c
- disk->ops->init(disk) | zephyr\subsys\disk\disk_access.c
  - disk_spi_sdhc_access_init()--> | if CONFIG_DISK_ACCESS_SPI_SDHC=y it will use functions from zephyr\subsys\disk\disk_access_spi_sdhc.c
    - spi_release() | zephyr\include\drivers\spi.h

At the blue layer, there are different choices for hardware interface, as you can see in zephyr/subsys/disk, but there is none for QSPI.

One option would be to create a driver yourself, in zephyr/subsys/disk/disk_access_spi_sdhc.c.

You could also use the API \zephyr\include\drivers\flash.h and set these in prj.conf:

CONFIG_FLASH=y
CONFIG_SPI=y
CONFIG_NORDIC_QSPI_NOR=y

You may also get some good answers if you ask in any of these Zephyr resources:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/zephyr/introduction/index.html#community-support

Best regards,

Simon