• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 3138 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SPI access from multiple tasks

pixbroker
Genius 5820 points
Other Parts Discussed in Thread: CC2640

I am using tirtos_simplelink_2_13_00_06 on a CC2640. My custom board has 2 SPI devices. My app has 2 tasks. Each of these tasks is reading and writing to one of these SPI devices. Both of these devices share the same SPI bus. 

The SPI access to each device works fine individually, but not when accessed simultaneously from each task. So this lead me to believe that the SPI driver can't handle this use case properly. 

What is the recommended practice to access the SPI driver from multiple tasks? Is it possible to use 2 SPI channels, that both use the same physical SPI pins or should the SPI driver access be protected by a Semaphore? 

Thanks.

  • 0
    TI__Guru* 96960 points
    Hi,

    You can use one SPI driver instance, but you'll need to manage the chip select as needed in your code. We are looking into moving the chip select management into the driver, but do not have a time-table for the enhancement.

    Todd
  • 0 in reply to ToddMullanix
    Genius 5820 points
    Thanks for the quick answer Tood. I am managing the CS for the 2 devices manually via the PIN driver and that part is pretty straightforward. However, i am seeing some SPI r/w issues when both tasks try to access the driver at the same time.
  • 0 in reply to pixbroker
    TI__Guru* 96960 points
    I'm assuming you are using the same SPI object in both tasks...correct? There is a check in the SPI_transfer code to make sure that you don't try to have multiple transfers going on at the same time (for the same channel). You need to provide that protection for the chip select though. For example, if you are in the middle of a transfer to SPI device A and you change the chip select to device B, the transfer for device A will be messed up. So basically, if a SPI port has more than one device that could be accessed at the same time, you need to provide the mutual exclusion (e.g. semaphore) around the chip select and SPI_transfer calls.
    I know this a pain and that's we are looking into moving the CS handling into the driver.

    Todd
  • 0 in reply to ToddMullanix
    Genius 5820 points
    Ok, thanks for the detailed explanation. That makes sense and i could probably add that. Before i go off and do that, is there any other way to deal with this? i.e. 2 SPI channels?
  • 0 in reply to pixbroker
    Genius 5820 points
    In the SensorTag BSP code, i have noticed a spiFlush function. Is this something that one needs to consider when using multiple SPI devices on the same physical SPI bus with TIRTOS?

    /*******************************************************************************
    * @fn bspSpiFlush
    * @brief Get rid of garbage from the slave
    */
    void bspSpiFlush(void)
    {
    /* make sure SPI hardware module is done */
    while(SSIBusy(((SPICC26XX_HWAttrs*)spiHandle->hwAttrs)->baseAddr))
    { };
    }
  • 0 in reply to pixbroker
    TI__Guru* 96960 points
    I'm not familiar with the bsp code. The TI-RTOS SPI driver functionality is self contained. So I don't think you should be using BSP calls.

    Regarding the other question...you could have the two SPI devices on separate SPI channels and everything in the software is easier. But of course you are using two ports now.
  • 0 in reply to ToddMullanix
    Genius 5820 points
    Todd, just following up, did you guys even move the chip select into the driver? if so what version of TIRTOS is the first to support this? Thanks.
  • 0 in reply to pixbroker
    TI__Expert 7250 points
    Hi ,
    We generally discourage posting a new question to an old closed thread because the person who answered before may no longer be available, and also it will allow whomever is currently assigned to monitor the forum to respond to you more quickly. For these reasons, I suggest you start a new thread with your question and reference this thread.

    Thank you