Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

awneil — Fri, 07 Aug 2020 06:24:56 GMT

[quote userid="75667" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave/263506"]There's nothing electrically to prevent this from working[/quote]

Follow the links where I cited some reasons for avoiding this configuration. They are not electrical - they are to do with the way SD Cards communicate on the interface - in particular, when an SD Card starts up, it is not in SPI mode.

I didn't say it can't be done - just that there are issues to consider.

An SD Card is not just another SPI Slave.

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

wpaul — Fri, 07 Aug 2020 01:30:00 GMT

[quote userid="80584" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave/263486"]Hello, it's been a year but I have tried all what you said. [/quote]

I don't believe it took you a whole year. It's really rude to disappear for so long and then come back expecting more help. 😞

[quote userid="80584" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave/263486"]It won't let me initialize FATfs blkdev without unitializing the SPI instance I have for the other slave I want to share the bus with.[/quote]

It's also really rude to only give a short sentence about your problem without giving any details or showing example code.

Please note: the Nordic SDK probably contains its own diskio.c code to interface with FatFs. If it's that code which is giving you trouble, then you may need to customize it. However I'm not going to do that for you.

-Bill

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

wpaul — Fri, 07 Aug 2020 01:20:18 GMT

This isn't true. If you want to recommend that people avoid this configuration, do it for the right reason: it may be a little hard for newcomers. There's nothing electrically to prevent this from working as long as you do it right.

I've designed two boards where a single SPI controller instance was used with multiple slaves, including an SD card. The first design (NXP Kinetis KW01 chip) had three devices: an XPT2046 touch controller, ILI9341 display chip and an SD card all on the same SPI channel. With the nRF52840, I the design had just the SD card and XT2046 controller on the same SPI bus. Both designs worked fine.

The things to remember are:

- each slave uses the same SCK/MOSI/MISO pins, *but* each slave must be wired to its own chip select pin (as the hardware designer, you have to make sure this is true)

- you have to be sure to only assert the chip select pin for one slave at a time when doing SPI transfers (assert CS1/do a transfer/release CS1, assert CS2/do a transfer/release CS2/etc...)

- for each slave device, figure out what's the fastest clock speed it can support, then see which one is the slowest -- set the SPI controller clock frequency so that it doesn't exceed this slowest speed

- if you're using an RTOS (i.e. you have threads), use a mutex to guard access to the SPI controller (i.e. always take the mutex before doing a SPI transfer and then give the mutex after)

Note that the rule about choosing the slowest clock speed can be fudged a little. With the nRF52840, I found you can actually change the FREQUENCY register on the fly without having to reinitialize everything. This may be necessary if the slowest slave's max speed is so slow that using with the other slaves would result in them performing too poorly for your needs.

That means you can switch the clock to low frequency only when you talk to the slow slave, and then switch it back to a higher frequency when you're finished.

Also, I'm not necessarily suggesting that people *should* share one SPI controller with many slaves, but I know that you *can* do it if necessary and it will work.

I think the real complication here is figuring out how to make this work with the Nordic SDK in particular. For the boards I worked on, I did not use the Nordic SDK. (In fact I wrote my own driver for the nRF52 SPIM device.) I don't know if there is a working example in the SDK that shows how to use a single SPI controller with two slaves. If there is, then that's the model that should be followed here (and the fact that one slave ends up being an SD card shouldn't really matter). If there isn't such an example, then they really ought to add one since while it's not a great idea, it's not an especially rare use case either.

-Bill

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

awneil — Thu, 06 Aug 2020 19:37:39 GMT

As I said early on in the thread:

[quote userid="6462" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave/202233"]In general (not specific to Nordic), I would always try to avoid sharing an SD-Card with any other SPI device. I don't really think that SD-Cards are designed to share their SPI interface [/quote]

See: https://devzone.nordicsemi.com/f/nordic-q-a/63517/interfacing-between-nrf52840-and-bme680-i2c-or-spi/258966#258966

and: https://devzone.nordicsemi.com/f/nordic-q-a/63570/adding-sd-card-as-second-spi-slave/259181#259181

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

jgvillap — Thu, 06 Aug 2020 16:12:23 GMT

Hello, it's been a year but I have tried all what you said. The main problem seems to be the FatFs itself. It won't let me initialize FATfs blkdev without unitializing the SPI instance I have for the other slave I want to share the bus with.

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

wpaul — Tue, 06 Aug 2019 21:41:10 GMT

I just went to look at the documentation again, and I need to make one clarification/correction. The SPIM controller block in the nRF52840 has the hardware chip select feature, however I think you're using the nRF52832 chip, and that one doesn't have it. I forgot that you were using the nRF52832 when I was writing my previous reply. Sorry. 😞

However, note that when you call nrf_drv_spi_init(), you give it a pointer to an nrf_drv_spi_config_t structure. This structure has a member called ss_pin, where ss stands for Slave Select. This is also what I'm calling the chip select. While the nRF52832 doesn't let you control the slave select pin from hardware, the Nordic SPI driver code can do it from software. When you set a pin value here, the nrfx_spi.c or nrfx_spim.c code will internally call nrf_gpio_pin_set() and nrf_gpio_pin_clear() to control the chip select pin when you issue a transfer.

That's convenient if you only have one slave on the bus, but it doesn't work if you have two. I think the reason you're calling nrf_drv_spi_init() twice is that you're not toggling the chip select pin yourself: you're letting the Nordic SPI code do it for you via the ss_pin feature. So to go from one slave to the other, you have to keep re-initializing the SPI driver with a different ss_pin each time.

What I think you need to do is set the ss_pin value to NRF_DRV_SPI_PIN_NOT_USED. Then you can initialize the SPI controller just once. After that, you need to modify your code to add explicit calls to nrf_gpio_pin_clear() (assert the chip select) and nrf_gpio_pin_set() (deassert the chip select) into your code before and after you issue SPI transactions to the slaves.

In other words, you have to do this yourself instead of relying on the Nordic SPI code doing it for you.

Note that I'm not using the nRF SDK for my project: I'm running an RTOS called ChibiOS and it has its own drivers for the SPIM block in the nRF52 chips. Conceptually though, it works the same. Really all I'm doing is initializing the SPIM block once, which configures the pin select registers (i.e. sets which pins are MOSI, MISO and SCK) and programs in the desired bus clock speed.

Once the SPI bus itself is initialized, then I have to initiate SPI transfers from the different blocks that need to talk to the SPI peripherals. For the touch controller, I basically do:

- assert CS pin for touch controller

- issue SPI command to read the touch state

- deassert CS pin for touch controller

(The touch controller is very simple.)

I also have an SD card driver module sitting under FatFs. When FatFs needs to read a block, it calls the block read function in the SD card driver, which behaves similarly:

- assert CS pin for SD card

- issue commands to read a sector from the card (involves several SPI bus transactions)

- deassert CS pin for SD card

What's important here is to never have the CS pins for both the SD card and touch controller asserted at the same time. As I said earlier, I use a mutex to guard the bus, and both the touch controller code and SD card code have to acquire the mutex before they can do any SPI transfers. Since only one of them can acquire the mutex at a time, it stops them from both trying to talk to the SPI bus at once.

I hope that makes sense.

-Bill

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

jgvillap — Tue, 06 Aug 2019 19:40:23 GMT

Also, are you doing an nrf_drv_spi_init for your touch controller as well as a blk_dev_init for your SD card on the same instance? Or do you only do it once for both?

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

jgvillap — Tue, 06 Aug 2019 19:39:33 GMT

How do I disable automatic CS handling? Do I give config a null Chipselect pin when initializing SPI?

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

wpaul — Tue, 06 Aug 2019 19:20:32 GMT

I know that the Nordic SPI controller has a feature where you can tell it what chip select pin to use and it will toggle it automatically when issuing transfers. Are you using this feature?

Having the SPI controller assert the chip select line automatically is handy in that it saves you from having to manually toggle the GPIO pin yourself (there's some savings in code), however it really only works well if there is one slave, because the SPI controller can only control one chip select pin at a time, and each slave has a different chip select line.

If you are using the automatic chip select handling feature, then I could see how you'd have to reconfigure the SPI controller each time you decide to switch from using one slave to another. In that case, I would suggest that you stop doing it that way and manually toggle the chip select lines instead.

If you're not using that feature, then I'm not sure what could be wrong. For my current project I have an SD card and resistive touch controller on the same bus, and I can access both of them without needing to reconfigure the SPI bus in between. I do manually toggle the chip selects though.

-Bill

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

jgvillap — Tue, 06 Aug 2019 18:30:47 GMT

So I can get it to work if I uninitialize SPI in between SD card SPI transfers and other slave SPI transfers. Since it works I'll move forward with this but if someone has an idea why I have to do this let me know so that I can optimize this further.

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

jgvillap — Tue, 06 Aug 2019 14:54:06 GMT

Hello,

Sorry for not being clear. Channel 2 is SCLK, Channel 3 is MOSI, Channel 4 is MISO, Channel 6 is CS of SD card and channel 7 is CS of another SPI slave that isn't an SD card.

Basically, I'm at a point where the custom board has already been fabricated and I have only allocated enough space for one SPI bus. Therefore, I will try my best on this revision to make this work with one bus if possible.

I am currently not using an RTOS as we have deemed it not that useful right now since all the operations the device will be doing is very low frequency (0.5-10Hz) and they are not that complex.

I think for now I will use some sort of flag/mutex within the callback functions for both the SPI slave and the SPI Fatfs drivers to prevent simultaneous communication. I'll let you guys know what happens.

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

jgvillap — Tue, 06 Aug 2019 14:45:13 GMT

Damn, I didn't know that SD-cards were designed to have its own SPI bus. It's kind of too late now though since my custom board has space for only one bus. I will take note of that for future revisions.

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

wpaul — Fri, 02 Aug 2019 22:25:21 GMT

[quote userid="80584" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave"]1) Since, I don't need the two slaves to transfer simultaneously, should I have them use the same SPI instance?[/quote]

Usually it's more a matter of how may pins you have available on the chip. The nRF52832 has 32 pins and multiple serial device blocks that can be enabled simultaneously. I don't know how many you're going to use for your application, but if you have enough, putting each device on its own dedicated bus avoids contention.

I did build a project once where for various and sundry reasons I was forced to put 3 slaves on one bus -- sd card, graphics display and resistive touch controller chip. I used an RTOS, and to keep things from exploding, I used a mutex to guard access to the SPI controller. (Any time I needed to do a SPI transfer to one of the slaves, I had to acquire the mutex first, do the transfer, then release the mutex again after.)

I think the Nordic SDK examples are mostly single-threaded. That being the case, you may be able to get away without using mutexes, provided you manage your chip selects correctly and don't try to issue a transfer for slave B while a transfer for slave A is still in progress,

[quote userid="80584" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave"]3) Right now I am stuck where I write to SD card using sd_write() (Channel 6),[/quote]

I know this might make sense to you, but remember the "we can't see over your shoulder" rule. Tell us which channel is MISO, which is MOSI, which is SCK and which is CS.

Each slave should have its own chip select pin. When a slave's CS pin is asserted (pulled low), the it will listen to the MOSI/MISO/SCK pins on the SPI bus. If you're sharing a bus with multiple slaves, only one slave must have its CS pin asserted at any given time.

[quote userid="6462" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave/202233"]I don't know if the FatFs design assumes that it has exclusive control of the SPI lines.[/quote]

Well, if you do use an RTOS, there are two things to worry about:

- The SPI bus controller state

- The FatFs library's internal state

FatFs has the notion of a synchronization object, and it has an optional API called ff_cre_syncobj(), ff_del_syncobj(), ff_req_grant() and ff_rel_grant(). I think you need to define FF_FS_REENTRANT in order to use it. It's up to you provide implementations of these functions that make sense for your application.

If you have two threads in your RTOS which may both be accessing files via FatFs and they could be running concurrently, then you need to use the above mechanism to make sure FatFs itself stays sane.

However, if you're using SPI for your SD card, and you have another kind of SPI slave on the same bus (temperature sensor, display, etc...), then since that slave isn't using FatFs, the above synchronization mechanism won't help you. (The thread accessing files via FatFs will be using it, the thread talking to the other slave will not.)

In that case, you need to define a mutex to guard the SPI bus itself, and then make sure both the FatFs SPI driver and your other slave code both use it, so that both can't try to use the SPI bus at the same time.

This means that when you use FatFs to access files, you'll be taking two mutexes instead of one, but that's ok (as long as FatFs always takes the SPI mutex _after_ its own mutex).

To make a long story short, if you can spare the pins, it may be easier if you use two separate SPI buses.

-Bill

RE: Sharing a SPI bus with an SD card (FATFS) and another SPI Slave

awneil — Fri, 02 Aug 2019 21:33:32 GMT

In general (not specific to Nordic), I would always try to avoid sharing an SD-Card with any other SPI device.

I don't really that SD-Cards are designed to share their SPI interface.

[quote userid="80584" url="~/f/nordic-q-a/50584/sharing-a-spi-bus-with-an-sd-card-fatfs-and-another-spi-slave"]What part of the FATFS example needs to be done only once?[/quote]

I don't know if the FatFs design assumes that it has exclusive control of the SPI lines.

You'd probably have to check that with ChaN:

http://elm-chan.org/fsw/ff/00index_e.html

http://elm-chan.org/fsw/ff/bd/