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.

CC2540: Invalid Attribute Handle

Part Number: CC2540


Hi everyone,

I have 2 cc2540 chips connected to each other and communicating normally. After a certain amount of time, the communication disconnects and the client chip gives an error response "Invalid connection handle" and I can see 1024 as the hanlde (for the error response) in the sniffer. Before the error occured, the communication was running smoothly and the handles of the previous transmissions were also correct.

I scoured through the forums and the internet but I couldnt find anything other than restarting the Bluetooth chip to solve the issue. Can someone please help me with this issue?

  • Hi Muhammad,

    What request is the Error Response sent in response to? Can you post the request packet as well?
  • It is normal GATT notification. Three notifications are sent in each connection interval but in some case we get an error response not sure why

  • Hi,

    I’m working with Muhammad on the same topic, in the screenshot below you will see stack frame at the error occurrence time. The last message sent from the server side has been received on the client side successfully (as shown in the memory section). We can’t debug the function “gattServerProcessMsgCB” to understand the reason behind triggering the ATT error response (error code: invalid handle).

    In our Project the BLE stack version 1.4.2.2 is used.

  • Hi,

    In the error response packet, it says the requested opcode is ATT Prepare Write Request. However it doesn't look like you sent any request like this.

    How often does this happen? Can you give me steps to reproduce this here?
  • Hi,

    I have seen the requested opcode in the ATT error response and this case might happen when the client side tries to send a packet with GATT_WriteNoRsp() and at the same time receives a notification from the server side.

    Is it possible to send and receive simultaneously or it is better to use the ping-pong principle ?

    This error occurs frequently but at irregualr intervals by an average of 25 minutes.

  • We are transferring 4 packets (20 bytes each) per connection interval without acknowledgment. The communication and the data transfer seems to run fine until this error occurs out of nowhere.  We are not sure how to reproduce this error but reducing the timeout for sending Bluetooth message at the application layer causes error to occur a bit faster.

  • Hi,

    As long as you're processing every event correctly in the application it shouldn't be an issue that the client receives a notification and transmits a GATT_WriteNoRsp() packet in the same connection event.

    That being said, from the sniffer log it does look like there is normally a gap between the three slave notis and the three master writes that is not there before the error response. (I'm just looking at the packet number, since the time stamp is not included in the screen shot.)
  • Hi,

    I have attached the trace from the sniffer where you can see all the frames with timings for the connection.

    We are using the Frontline Protocol Analysis System 14.3 which is free to use for capturing the Bluetooth data.

    Thank you in advance.

    Regards,

    Muhammadhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/x430_5F00_003_5F00_60_5F00_test3.7z

  • Hi Marie H,

    Could you please explain in a few words the conditions which could trigger the ATT error response (invalid handle) in case of receiving a GATT notification.

    I have tried to debug the error in assembly mode but it was not easy to understand the program flow.

    GATT_ProcessEvent -> gattProcessRxData -> gattServerProcessMsgCB ->ATT_ErrorRsp.

    I think it might be an alignment problem to access the memory where the received message is buffered.

    Thank You.

  • Hi,

    The GATT notification procedure is described in BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part G, chapter 4.10 CHARACTERISTIC VALUE NOTIFICATION. There is no case in this procedure that leads to an ATT error response packet being sent.

    As far as I can tell, your bug is in the device transmitting the ATT Error Response packet. This packet seems to come out of nowhere, not being sent in response to an actual request.