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

BLE stack timing constraints

bob frankel
Expert 2460 points

while the OSAL task scheduler *prioritizes* BLE tasks over others, the scheduler itself is not *preemptive* but rather *run-to-completion*....  said another way, lower-priority tasks have to "co-operate" by returning from their event-handling function (called in OSAL.c) in a timely manner....  if not, events pending (say) for the BLE tasks will not be handled within bounded periods of time....

my question, then, is this:  what is the *worse-case* latency that the BLE tasks can tolerate????   said another way, if my (lower-priority) task does not handle its events in less than 'N' milliseconds, the BLE stack itself may for instance start dropping connections....

i'm not sure what 'N' is a function of -- some "keep-warm" rate at the LL level?? -- nor am i sure whether 'N' varies based on some config setting....  either way, it would be helpful to publish timing constraints that other code executing on the 8051 must respect...

thanks in advance

  • 0
    TI__Expert 6840 points

    This is my general and limited understanding, but this may help.

    The controller will basically stop the application processing to run the radio at connection events.  So while the radio the sending out packets, the app is stopped. The controller is setup to tx  a max of 4 X 80 byte packets per connection event so this duration does not have a big impact.   One advantage of this is lower peak power during tx, but this will also put limits on long operations like writing to flash.

    Br,

    -Greg

  • 0 in reply to GregS
    Expert 1880 points

    I have a question close to this issue - noticed if I do something which takes too much time in the Profile_ReadAttrCB or WriteAttrCB functions the connection between the dongle and the keyfob will be dropped. Noticed this when I tried to write bigger data chunks into the flash which is really slow and I know it is not recommended writing flash from those BLE stack callbacks. Probably what happens is, that the dongle timeout's waiting the answer for the last read/write operation.

    I could make it work moving flash operation to seperate events as it is recommended by the guide but I am wondering if anyone knows what is the maximum time what can be spent inside of those read/write callbacks without killing the BLE connection?

    This completly depends from the BLE parameters like connection intervals, slave latency and timeout multipliers or it's a fixed amount of time which is coming from a BLE read/write action?

    I am not sure if it's related to the connection interval and other BLE params, since the whole action happens inside one read/write operation - the slave receives the read, the BLE stack calls those callbacks to notice the user firmware about the read and on return sends back the value via BLE. If this return is delayed too much connection is dropped.

    Br,

    B.

  • 0 in reply to Barna Csenteri
    Expert 2460 points

    this is exactly the heart of the matter....

    but i'm also curious if moving long-operations (eg., writing flash) to separate events is really the answer....  my assumption is the underlying event dispatch mechanism is *not* preemptive -- tasks have to (cooperatively) return from handling events before the OSAL can dispatch posted events to the highest priority task.... 

    my original question was effectively whether a long-running (but low-priority) task could ever starve BLE tasks....  for example, suppose my low-priority task was running when a "request" message came across the wire....  unless i return in a timely manner, the BLE task that would call the profile callback would itself never run, and no response would be sent back; this too could lead to a dropped connection....

    the bottom line is this -- there are "deadlines" that various task have to meet (though these can be functions of tunable parameters)....  we just to know what they are...

  • 0 in reply to bob frankel
    Expert 1880 points

    There is no other option with flash operation than moving it out from BLE callbacks - but in the same time i am also curious about the limits ... The flash stuff could be the worst since it's done via DMA and interrupts are disabled during transfer if I remember well ... 

    Also lot's of sensors are having SPI, I2C and other type of communication - a good example is the one from SDK (CMA3000d acceleration sensor) which have both. Talking with those devices needs sleeps, timings and lot's of stuff which are also delaying callbacks in certain cases ...

    And the whole situation can change quite much depending from the BLE parameters like connection intervals, timings which are setable runtime by the master in a connection ... 

  • 0 in reply to Barna Csenteri
    TI__Expert 6840 points

    Hello,

    Here is text from our 1.0 version (only known issue)

    ============================================

    Known Issues:

     - Use of the NV memory (to save application data or BLE Host bonding

       information) during a BLE connection may cause an unexpected disconnect.

       The likelihood of this happening increases with frequent usage, especially

       when using short connection intervals. The cause is related to the NV wear

       algorithm which at some point may cause an NV page erase which can disrupt

       system real-time processing. It is therefore recommended that the NV memory

       be used sparingly, or only when a connection is not active.

    ===============================================

    Still, it should be OK  if triggered after a connection event and with a longer connection interval, > 200ms.  There are no hooks right now to tell when the RF will be active, so it's hard for the application to schedule this.   The timing for these writes is listed at around 20ms in the CC253x/CC254x user guide. Changes are being planned to address this in next release.

     

    Br,

    -Greg