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

Problematic with BLE and SPI Interrupts, BLE blocking interrupt handling

Sebastian H
Prodigy 40 points
Other Parts Discussed in Thread: CC2650

Hello,


I have a Question about BLE usage and interrupt handling from SPI.


Overview to my setup:

I'm using two SensorTag devices (CC2650) communicating over Bluetooth Low Energy (BLE). One as Peripheral (BLE Stack 2.0) and one as Central (BLE Stack 2.1). The Peripheral one has some SPI communication to mounted sensors. Interrupts from the sensors to GPIO Pins indicate new measurement values. After an interrupt the simpleBLEPeripheral task will gather the new data and store it in a characteristic.  (BTW: im not able to use any kind of data storage on the sensor itself, so i have to get the data out as soon as new data arrives!)
The central reads the characteristic (size: 250 byte) every 22.5 ms (Read_Req -- 7.5 ms --> Read_Rsp with data (takes 2 cycles because of the huge amount of data -- 15 ms --> next Read_Req). Both Devices work with a MAX_PDU_SIZE of 255.

So far, so good.

The following picture shows the Interrupt Pins, the Interrupt Handling and the SPI communication to gather the sensor data in non-connected state.

Yellow: SPI interrupt on GPIO Pin (active low)
Green: - Going high in SPI Interrupt Callback, then notify app and enqueueing the Msg.
             - Going low on processing the Msg in SimpleBLEPeripheral_processAppMsg
Blue:   Shows the actuall SPI Communication in the SimpleBLEPeripheral_processAppMsg function.

But as soon as the Central initiates a connection with the Peripheral the SPI communication changes.

The next picture shows the problematic:
The interrupt is still notified and enqueued, but the simpleBLEPeripheral task won't be able to handle the Msg for about ~1.5 ms. So the app tries to gather two times the data from the sensors after the timeout.
But in this case the data is gone.

Yellow: SPI interrupt on GPIO Pin (active low)
Green: - Going high in SPI Interrupt Callback, then notify app and enqueueing the Msg.
             - Going low on processing the Msg in SimpleBLEPeripheral_processAppMsg
Blue:   Shows the actuall SPI Communication in the SimpleBLEPeripheral_processAppMsg function.

Same picture but a wider time range ( time between the problematic: 22.5ms)

It has to do s.th. with the BLE communication, but i can't figure out what the CPU is doing in this time and how to get the CPU to handle my SPI communication in this case. Otherwise i can't gather reliable data.

I hope you can tell me what the CPU is doing in this time and how i'm able react on interrupts in a reliable way.

Regards,

Sebastian H.

  • 0
    TI__Guru** 105180 points
    Hello Sebastian,

    I strongly suggest that you use BLE 2.1 or integrate a newer SPI driver from a later TI-RTOS release.

    Have you tried slowing down the BLE Connection Interval? The BLE Stack task will run based on the connection interval rate. It runs at the highest priority, so the App task will be blocked when the Stack task is running.

    Best wishes
  • 0 in reply to JXS
    Prodigy 40 points

    Thanks for your answer.

    Unfortunately this does not change anything. I still have the same issue. Also it isn't possible for me to slow down the BLE Connection Interval, because i need this huge amount of data thoughput.

    Are there any other options i can try or any possibilities to minimize pre- and post processing of BLE?

    Regards,
    Sebastian H.