• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 1441 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.

CC2640 running SPI as a slave

Nad Gilbert
Prodigy 200 points
Other Parts Discussed in Thread: CC2640

I have a custom part that can only run as a SPI master device.  I would like the CC2640 to act as SPI slave to receive data from it.  I've been able to get it work but I have to have the main processor in active mode.  The timing is still sketchy and the BLE seems to also cause problems.  I would like to have it in idle mode at least most of the time and really fine tune the timing.  It seems like I would have to program a custom SPI interface into the GPIO controllers.  It seems like this can be done with a SPI driver.  Has any one done this?  Would anyone like to do this?  Is it possible to write a SPI driver for the CC2640 so that the main processor can be in idle while it is acting as a slave?

Thanks,

Nad

  • 0
    TI__Mastermind 29650 points
    Do you have some kind of handshake protocol available that you can use to wake the device from Standby? If not then Idle is the lowest power mode available as you need something to wake you up again with (e.g. wake on IO).

    Assuming you know when the master device plans on sending you data you can simply set up a SPI transfer with the CC2640 as slave. The driver will handle power management for you and ensure the device do only stay in Idle while the transfer is ongoing.

    An example is found in <tirtos_install_path>/docs/docs_overview.html -> TI-RTOS Driver Runtime APIs (doxygen) -> SPICC26XXDMA.h

    Regards,
    Svend
  • 0 in reply to svendbt
    Prodigy 200 points

    Svend,

    Thanks for taking the time to reply.  The timing is an issue.  The master device is designed to  send out  several commands to communicate with it's intended system.  The CC2640 has to monitor those commands and know, by timing and known command structure, where the actual data is.  The only way we've been able to get it to work is by running the CC2640 in active mode and synchronizing with the BLE events.  This still seems to be unreliable because we continue to loose sync with the master device.  Is there a way we can ensure the part is in idle?  Are there TI engineers we can talk to or hire to help look at the problem?

    Thanks,

    Nad

  • 0 in reply to Nad Gilbert
    TI__Mastermind 29650 points
    I would look into keeping the device in Idle by always having a SPI transfer of data enabled and process them afterwards.
    You can potentially add timing information by e.g. doing a capture on e.g. chip select using a RTC channel or a high speed timer and use this when post-processing the data that arrives if you don't want to depend on events from the BLE stack.

    Regards,
    Svend