File transfer from SD Card to WiFi using nRF5340 and nRF7002 - recommended signal wiring

[Bruno Saraiva]

The question is not only "software" related, it is also debating the hardware topology:

Part of a project's goal is to transfer files stored in a uSD Card to an external client via WiFi (all with Zephyr). The controller is a nRF5340, and the WiFi module is nRF7002.

The discussion here is what would be the most efficient signal connection, considering that:

- Both peripherals (SDCard and WiFi companion) can communicate to the CPU either via regular SPI or via QSPI.

- QSPI is much faster than SPI, so an immediate comment is that connecting the WiFi module via regular SPI will limit the speed.

- But if we have both in the same bus, I assume that DMA is impossible. So a buffer inside the CPU would be needed.

So what is the best bet?

SDCard -> QSPI -> CPU buffer -> QSPI -> nRF7002 (same QSPI bus with different CS signal)

SDCard -> SPI -> CPU DMA -> QSPI -> nRF7002

SDCard -> QSPI -> CPU DMA -> SPI -> nRF7002

That is, assuming that Zephyr and the IC will actually allow for such direct DMA, and that it is possible to transfer content from SD to WiFi just like that (most likely the Zephyr TCP stack will have to manage the packages first).

Cheers

Bruno

[Turbo J]

You can't use the QSPI peripherial with an SD card, so only method 2 is possible.

[Bruno Saraiva]

Thanks for the quick feedback!

Really no QSPI for SD allowed?? Do you have off hand any document reference to that?

The current version of our product has SD Card, and I know that the traces were routed between the nRF5340 and the uSD as QSPI. Also, I can confirm that the product works (writing/reading lots of files to the uSD).
But I was not involved in the software, so maybe my colleagues configured those pins as regular SPI instead and I never knew it...

Or a separate point: do you know if the data transfer can be really "raw bytes" from the SD to the nRF7002, and the TCP packages are dealt inside that component, or is it handled by the code that runs inside the nRF5340?

[Håkon Alseth]

The QSPI peripheral is targeted for NOR based flash operations on both nRF52840 and nRF5340, and will not work with an SD card.

SD cards also require an additional license:  RE: nRF5340, QSPI and micro SD 

 

Kind regards,

Håkon

[Bruno Saraiva]

Thank you for the comments and the links. 
I had no idea about this SD license requirement!

As for the original question, we will be adopting the only possible option:
"SDCard -> SPI -> CPU DMA -> QSPI -> nRF7002"

[Håkon Alseth]

Hi,

 

Bruno Saraiva said:

"SDCard -> SPI -> CPU DMA -> QSPI -> nRF7002"

We do not have generic DMA channels, so this is not possible, unfortunately.

 

Kind regards,

Håkon

[Bruno Saraiva]

Ok then...
"SDCard -> SPI -> DMA -> CPU RAM Buffer ->
CPU RAM Buffer -> DMA -> QSPI -> nRF7002"

[Håkon Alseth]

Hi,

 

You'll need to involve the CPU in the process, but the payload also needs to be encapsulated through the TCP/IP stack as well.

 

Kind regards,

Håkon

[Bruno Saraiva]

Do you or any colleague has written a speed test for transferring SD card files via WiFi using 5340 and 7002? I wonder what the numbers would show and where the bottleneck would be...
Unfortunately I really don't have the time to learn to write such test, but being something relatively common, it would be useful for many other customers.
We are proceeding with the design anyway, but aligning the expectations up front will be useful.
Thanks!

[Håkon Alseth]

Hi,

 

My apologies for the long wait.

 

Unfortunately, we do not have a sample that does exactly what you require at this time.

We have an open PR for the download sample, where we are adding nRF7002 support. However, this is currently work-in-progress:

https://github.com/nrfconnect/sdk-nrf/pull/11547

I would recommend disabling CONFIG_LOG and also disable CONFIG_DOWNLOAD_CLIENT_RANGE_REQUESTS to get better performance at this time. Reason for this is that the internal download thread is running on the same priority as the log thread, which will cause a performance hit.

In addition, there is currently a progress-print that you can comment out in main.c:

https://github.com/nrfconnect/sdk-nrf/blob/3a85b431d94137081e76ee48dce873ef8412211c/samples/net/download/src/main.c#L187

 

Again, this PR is not currently optimized for speed and is a work-in-progress. The maintainer of the PR is aware of this.

 

Kind regards,

Håkon