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.

CC2640R2F: GATT Write error

Part Number: CC2640R2F


Hi,

I am using the example projects ble5_multi_role project  and ble5_simple_peripheral prjects running on two CC2640R2F Launchpads, multi_role acting as the client and the peripheral as the server.

My SDK version is 1.35.00.33.

Once connected, I use the keys on the Launchpad to perform read/writes to the characteristic on the peripheral.

But when I try to automate this process, there are some situations where this fails.

For example, I try to perform a write immediately after the characteristic is discovered i.e.:

if ((pMsg->method == ATT_READ_BY_TYPE_RSP) &&
(pMsg->msg.readByTypeRsp.numPairs > 0))
{
// Store handle
discInfo[connIndex].charHdl = BUILD_UINT16(pMsg->msg.readByTypeRsp.pDataList[0],
pMsg->msg.readByTypeRsp.pDataList[1]);

//perform write here
mr_doGattRw(0); //No other connection, hence index is 0

}

the write attempt fails and I don't see any  change on the peripheral side.

However, if I start a clock at the same place instead i.e.

if ((pMsg->method == ATT_READ_BY_TYPE_RSP) &&
(pMsg->msg.readByTypeRsp.numPairs > 0))
{
// Store handle
discInfo[connIndex].charHdl = BUILD_UINT16(pMsg->msg.readByTypeRsp.pDataList[0],
pMsg->msg.readByTypeRsp.pDataList[1]);

Util_startClock(&testingClock);

}

with a delay of 5 seconds, and then perform the write when it times out, the write goes through.

i experimented with a couple of delay values i.e 1s, 2s and 5s. I found that the write is successful for 2s and 5s but fails for 1 s delay.

What's  going wrong?

 

  • Hi Addarsh,

    This issue should only occur when there's already another ATT operation in progress. If you look at the returned status what does it say?

    You should be aiming for a success being returned when the GATT_Write is issued. The delay you're using is probably allowing the ATT transaction to finish up, allowing for another.

    What you could do is similar to what's done on the github examples on longrange_central and throughput_central, is post an event for the application to process and send a write. If it's not a success, free the resource and re-post the event until success.

    I hope this helps,

    Regards,
    Rebel
  • Hi Rebel,

    Yes that worked. Thanks.

    But isn't this a very bad API then? Ideally the BLE stack should take care of buffering any pending writes instead of sending immediate errors.

    Cheers,

    Addarsh 

  • Hi Addarash,

    Then the stack's RAM usage would get out of control! (At least that is what I'd assume would happen)

    It's due to the Bluetooth Specifications, most Attributes need to be acknowledged in one way or another before another one can be sent.

    This allows bluetooth to reliable and not drop packets.

    Regards,
    Rebel