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.

CC2340R2: ATT_READ_RSP with 0 byte payload

Expert 4545 points

Part Number: CC2340R2

Hi team,

Customer is using the CC2340R2 on SDK 9.11 and we are unsure what the behavior of the BLE stack will be in the following edge case:

If the phone sends an ATT_READ_RSP (0xb) with a payload of 0 bytes, will that read response be passed to their application?

They are testing a scenario in which their product attempts to read the device name of the phone. The phone sends the response with no payload because they cleared the device name from the phone. The PDU length is 1 which is the length of the opcode but there is no data. From what I can tell their application code is not seeing the ATT_READ_RSP. Do you know what the TI BLE stack will do in this case?

Best,
Luke

  • Hi Luke,

    Thank you for reaching out! I would expect the ATT_READ_RSP to make its way through to the application. Can you confirm with the eventHandler if they have registered for that kind of event? If they have, can they confirm they can get non-zero length msgs through?

    Best Regards,

    Jan

  • Hi Jan,

    Thanks for the quick response!

    Yes, they are registered for the ATT_READ_RSP event. And yes, they get non-zero lengths thru. They only have an issue with zero length messages and they don’t check the payload length anywhere in their code.

    Best,
    Luke

  • Jan,

    Did some more debugging and as far as we can tell the BLE stack is not passing along the event if payload length of ATT_READ_RSP is 0 bytes. This behavior seems unexpected, no?

    Best,
    Luke

  • Hi Luke,

    Got it. Yes, that does seem unexpected. Can they try on the 9.20? I would like to verify this isnt something that has been fixed in the latest release.

    Best Regards,

    Jan

  • Hey Jan,

    Good news. They realized there was an issue in building their code as we were debugging this issue – some of the updated files were not being built. Once fixed, they were able to see the BLE stack was passing the event with the payload length equal to their application. So adding code to check payload length fixed the issue.

    Thanks for the support,
    Luke