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 v1.3 GAP and GATT callbacks out of order

Our Peripheral application has registered callbacks with GAP and GATT (GAPRole_StartDevice and GATTServApp_RegisterService respectively).  We have encountered a situation where these callbacks are called out of order.  

This is triggered by a Central device which uses unacknowledged GATT writes and the problem occurs when the Central device sends a write command followed by a disconnect command in the same connection interval.  We're seeing the Peripheral callback indicating a disconnect and sometime later the GATT write callback is called; from the application's view, the write occurs after disconnect.  

This issue exacerbates the problem of not being able to write to NV RAM while connected because we're using the disconnect indication to trigger the committing data to NV RAM.

Here's the sequence we see:

GAP callback - GAPROLE_STARTED

GAP callback - GAPROLE_ADVERTISING

GAP callback - GAPROLE_CONNECTED

GAP callback - GAPROLE_WAITING  (indicates disconnect)

GAP callback - GAPROLE_ADVERTISING

GATT callback - Write attribute callback

  • Hello Richard,

    I have read over your problem, but it appears to me that it is doing what you are asking.  Your alternative is to place your writing of the data in the GAPROLE_WAITING event.

    Thanks,

  • One expects that callbacks would occur in the same order that events occur over the air.  It seems wrong to receive data after the link has been disconnected.  Obviously we can code around the issue knowing now that events occur out of order, just wanted to alert TI and the community to this issue.