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

BLE cc2540 connection issues with SPI transaction

Pradee Kumar
Prodigy 40 points
Other Parts Discussed in Thread: CC2540

Hi,

I'm using Ti CC2540 for BLE. In the application cc2540 needs to send periodic updated at 4sec rate. The data is received from SPI master which is STM32F4

on SPI. However I'm facing some issues with SPI integration. As soon as I starts my SPI task, the BLE radio behavior changes, I 'm not able to discover it 

from  BTool. I've to reboot it 2-3 times and quickly issues scan request. to discover else I'm not able to discover it. Even when the device is discovered I'm not able to connect to it. I've to again power cycle it to establish connection. 

However If I switch off my SPI task the device works perfectly, I'm able to discover it in one go and also able to connect without rebooting. All the messages are perfectly received.

I think BLE  link layer timings are getting affected by the SPI task. But I'm still not able to figure out.

For initial test the  SPI transaction happens once in ever 2 seconds with 10 bytes exchange which is not much. In actual application there will more than 40 bytes exchange at 4seconds rate which further worries me.

I've used SimplePeripheral_BLE as my starting code base. and my SPI communication framework is based on hal_uart_spi example provider with HAL driver.

However I'm using SPI in interrupt mode without DMA and synchronization is carried using external GPIO pins.

The SPI is running at 1.5MHz clock.

Please someone provide some suggestion or direction where I'm going wrong. 

Thanks and Regards,

Pradeep

  • 0
    Prodigy 40 points
    Another thing I notice is that when ever I get external interrupt as start of SPI transcation I'm clearing device sleep mode by call CLEAR_SLEEP_MODE() in ISR and also before initiating SPI transfer. However If I don't clear out these sleep modes and comment CLEAR_SLEEP_MODE(). Then radio works fine, I'm able connect and disconnect the device smoothly without power cycle. But my SPI communication goes off. The BLE device no more transmit on SPI. I used oscilliscope to probe miso lines.
    So surely SPI and radio are conflicting. Please suggest what I'm missing. Do i need to use DMA?

    Thanks and Regards,
    Pradeep
  • 0 in reply to Pradee Kumar
    Prodigy 40 points
    Can someone provide some suggestion for this?
  • 0 in reply to Pradee Kumar
    Prodigy 185 points

    I've been able to get the CC2540 to work as an SPI slave to an external MCU even using polling/waiting though there are risks in doing it this way and I only did it as an initial approach for testing.  The recommended approach is to use DMA and this is shown in the _hal_uart_spi.c file.

    It sounds like you may be doing your SPI transfer from within your ISR and that is not good.  An ISR needs to be short and fast so all you should do there is set an OSAL event and then do your SPI transfer in the event loop in the SimpleBLEPeripheral_ProcessEvent function (or equivalent).  Because the CC2540 may be asleep when the SPI master wants to do a transfer, you should have the CC2540 send a signal to your external MCU to indicate when it is ready for the transfer to start since it takes some time to wake up.

    If you use DMA, then you can either arm it when you get a request for a transfer and then you indicate that you are ready, or you can keep it armed (and re-arm it after each transfer) and just use the interrupt signaling to tell you when there is transferred data to process -- that is, you can trigger on when the Enable line (SSN slave select pin) is released back up after the transfer is completed.  DMA is tricky because of all the various TI H/W bugs that exist including not always handling VLEN consistently, dropping the last byte on an output transfer, etc.  The _hal_uart_spi.c works around all of these issues, but it's not the only way.  If you have a well defined protocol then you can know in advance the length of transfer you expect at each phase of the transaction that may have multiple transfers.

    Another reason to use DMA is if the CC2540 does any interrupts during your OSAL processing.  With your 1.5 MHz clock for the SPI, that means each byte transfers in 5.3 microseconds.  Any interrupt that occurs during this time could affect your SPI code.