• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 2069 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.

RTOS/CC2640: SPI transfer call in a SPI callback...

Matthias Mueller
Intellectual 380 points
Part Number: CC2640

Tool/software: TI-RTOS

Hi Forum

I have a problem with the SPI callback:

We have made a special sensor board, which will stream a lot of data from a sensor via SPI in a short time to an external FRAM. The sensor has an internal FIFO which will trigger a GPIO interrupt if it is full. Unfortunately, I need to read out the data from the sensor FIFO byte-wise, a complete SPI read command per byte because this is how the sensor was designed :( I have now some issues, how to design this properly.

To handle this transfer, I have designed a state machine. The states will be changed via interrupts, e.g. an interrupt of the external sensor FIFO or a callback if the SPI transaction was finished. I have now discovered, that the SPI transfer could be so fast, that the interrupt will be set even if the current program pointer is still in the SPI-finished callback (I also issue transfers from within the SPI finished callback to be as fast as possible to read the FIFO byte-wise). I think this is the problem, because the RTOS hangs, if a very short SPI command is sent within the SPI finish callback.

I could now re-write the code to handle the SPI via blocking transaction, but is was written, that this is only possible within a task environment: this means, I can't directly transfer data via SPI on a FIFO GPIO interrupt...

Is there a possibility to trigger a new SPI transfer directly after another transfer is finished? Within a interrupt context? Or do I need to handle something like this in a task function context, and work with events?

I hope you could see my problem. If not, don't hesitate to ask.

Thank you very much in advance

Best Regards,
Matthias

  • 0
    TI__Mastermind 20480 points
    If the SPI is so quick, can't you just use the SPI in blocking mode?
    You wouldn't be blocking very long and I believe there are future plans with this driver where short SPI transfers will won't use the DMA (increasing the transfer rate).

    The point is, the GPIO interrupt and unblock a task from where you can call SPI_transfer one byte at a time quickly enough to empty the sensor's FIFO and you'd have the data immediately in your rfBux buffer.

    Tom
  • 0
    Expert 2225 points
    Hi Matthias Mueller,
    Do you read the number of data in FIFO? You can use a timer to polling the data in the FIFO of your sensor. You only set the frequency of timer larger than the frequency of sample rate of sensor.
  • 0 in reply to Luu Vy
    Intellectual 380 points

    Hi all

    I'm somewhat hesitating to use the driver in polling mode, because I use a GPIO as chip-select, because I have two SPI slaves (this would be an awesome addition to the SPI driver, if you could also specify a chip-select pin when calling SPI_transfer()). If I have two transfers to the same slave, the time where the chip-select is high could be too short. I will call PIN_setOutputValue(... 1) and then again PIN_setOutputValue(... 0) immediately after for the next transaction. This is only a guess and I need to verify, if it is really too short. But I will re-write the code and test it with the blocking functionality and let you know if this works.

    @Luu Vy: I can't use a timer, because the rate is very variable and the sensor is designed to signal via GPIO, if the FIFO has a certain number of entries

    Thank you all for your suggestions

  • 0 in reply to Matthias Mueller
    Intellectual 380 points
    Hi All

    I have now changed my code, so that the SPI finished callback triggers a event for the RTOS; this will then read the sensor data. For now, this solution works, and I did not had to completely re-write my code.
    I guiss, in the future, I will solve such an issue by directly using the SPI as blocking.

    Thanks agian
    BR
    Matthias