This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SPI SD Card, sharing same instance with another peripherals

Hi all,

I'm recently working with Nordic devices (more precisely nRF52840), so I'm still learning. I'm working on a project where I have a shared SPI bus with several devices (each with its own CS pin), and one of them is a SD Card. Initially, to validate the hardware I make use of the available SD Card library from the Nordic SDK, and it worked like a charm (only the SD Card). However, now I have to deal with the fact that I have other peripherals (sensors mainly) that also make use of the same SPI pins.

On our projects, our sensor drivers accept an external SPI instance (created on Main) and then, internally the driver controls the CS in a blocking way. And that works for all the peripherals that make use of the same SPI instance, basically it works in a synchronous way.

However I noticed that the SDK SD Card library doesn't accept that procedure, due to the fact that it creates internally its own SPI instance and deals with it in an asynchronous way. How can I solve it? Does anyone faced the same problem? I'm trying to interact with fatfs directly, but with no success until the moment...

Thanks in advance by your time!!

Miguel Roque

[EDIT: I had to reopen this thread because accidentality I closed the other post :( ]

  • BTW, I'm using the "sdcard" library available on SDK (together with the "fatfs example()"). The SPI instance is created inside app_sdcard.c and is created in accordance with a SPI handler (that uses to deal with the sd card operation). So it doesn't even admits to pass as argument an external SPI instance.

  • Hi Miguel,

    Are you using nRF5 SDK or nRF Connect SDK?

    Best regards,

    Dejan

  • Hi Dejan,

    I'm using nRF5 SDK v16.0.0

    Best regards

  • Hi Miguel,

    You may consider creating a function which converts asynchronous to synchronous function. Steps might include: creation of the SD card handler, starting the asynchronous function, waiting (before finishing) for signal from asynchronous function to continue. In the asynchronous function, you would ensure that the asynchronous function provides some kind of signaling to your function that it has completed what it was doing.

    Function for retrieving card busy state is called app_sdc_busy_check.

    SD card library usage (can be found on infocenter.nordicsemi.com) shows how to use app_sdc_busy_check function:

    {
    wait();
    }

    Best regards,

    Dejan

  • Hello Dejan,

    Thank you for your support, I did implement it. In addition I declared the SPI instance created by the sdcard library as extern and used on my main for the other sensors. However I still have no success, the sdcard indeed is initialized, however when I try to initialize my sensors (making use of the same SPI instance form sdcard), I cant make a connection with the sensor...

    Adding to your suggestions, I also changed the SPI handler function inside sdcard library in way to ignore any SPI actions that were not originated by the library its own. 

    Also, looking to the SPI lines using a logic analyser, I noticed that the MISO line is maintained in high level after the sd card initialization. Based on MMC/SSD documenatition this might be normal for some SD Cards models, and to force the mmc/ssd card to be an HighZ we should send 8 clock pulses while holding the CS line high. I did that also, but still with no success...

    Thats the situation point by now...

Related