• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 1030 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/CC2650: SPI_TRANSFER returns SPI_TRANSFER_CANCELED while RF_pendCmd

Crescenzo Mugione
Prodigy 100 points
Part Number: CC2650

Tool/software: TI-RTOS

Hi everyone,

I'm encountering some issues with CC2650, mounted on a custom board, communicating with a main MCU by SPI interface, where the CC2650 is the slave and the main micro is the master. I've implemented two tasks:

1) A task, that implements communication with the main MCU through SPI interface, that I've called SPI_TASK (SPI configured in Blocking mode without partial return)

2) A task, that implements communication with other RF devices, that I've called RF_TASK

I've seen that when I start to receive RF packets by posting rx command to M0 in RF_TASK, the SPI_transfer function returns with SPI_TRANSFER_CANCELED status.

If I do a RF_close the SPI_TRANSFER works correctly.

Thanks for clarifications

  • 0
    TI__Guru 58425 points
    Hi,

    Could you provide information on what SDK version are you working on so I could look up the related drivers?
    Also, could you maybe share a few code snippets on the SPI and RF tasks just so it is clear what you are doing and how it is setup? What is the size of the SPI transfers you are performing?

    Based on how the current SPI driver behave, there is only 3 ways leading to this status (one is actually calling SPI_transferCancel). The other two would be if the CSN was set to high during the transaction or if there as an RX overrun.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 100 points
    Hi,

    the SDK version is the 2.16.00.8, but, I've used the CC2640R2 SPI driver from BLE SDK 1.35.00.33, because, with the 2.16.00.8 SPI drivers after a first SPI transaction, the MCU was blocked.

    Regarding an eventually calling of SPI_transferCance, no task call this function, but I don't exclude that TI-RTOS can call it.
    For CSN, I have disabled partial return, infact, I've tried to stop on a SPI_transfer and tried to move CSN pin from main mcu, and I've seen that the task never return from SPI_transfer.

    For RX overrun, if you mean that the main micro could fill the spi dma buffer, I don't think because I found that when the issue occurs, the rxBuffer contains my initialization data (0xaa), so it seems doesn't sample on spi bus.

    Thanks for support
    Regards
  • 0 in reply to Crescenzo Mugione
    TI__Guru 58425 points
    Hi,

    There is no functionality in TI-RTOS that would cancel your transaction, you can exclude that for sure. RX overrun would mean that the SPI RX FIFO was not emptied by the DMA -> causing overrun. What is the TX/RX size of your transfers?

    Also, what type of RF Driver APIs are you using and what is the priority of the two tasks?
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 100 points

    Hi,

    thanks for quick response.

    The TX/RX SPI transfer size is 256bytes.

    The RF driver is a proprietary RF driver.

    Reasoning about your hypothesis about RX overrun, we have tried to reduce SPI transaction speed from 2Mbps to 1Mbps and now, it seems work fine.


    Is this behavior consistent for you?

    thanks a lot