This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

S130 v2.0.0-8 ble_gattc_evt_write_rsp_t wrong data??

Hello,

I was just editing the handling of sent packets and I wanted to evaluate the contents of the ble_gattc_evt_write_rsp_t struct which is part of the BLE_GATTC_EVT_WRITE_RSP i suppose. When I receive the event, I check the contents of bleEvent->evt.gattc_evt.params.write_rsp.data.

Data length is always reported as 0 for me and the data[] does not contain any valid data,... However on the client side I receive everything correctly. What does that mean? How is this event supposed to work?

Marius

Parents
  • I doubt you get the data back for a normal write because for a normal write the bluetooth-level response is just a response code and nothing else. I would expect to see that data filled in only for long and reliable writes where the data is sent back from the server as part of the reply.

  • Alright, thank you. have to solve it differently then. I was thinking the SoftDevice has a buffer for a WRITE_REQ in which it keeps the data because it might need to resend it. so I thought it could as well deliver that data back to me when it creates the WRITE_RSP event. But maybe this data is deleted early so that the slot can be used again before the user has processed the WRITE_RSP event. (Well, and sending a new WRITE_REQ while handling this event would be a problem.)

    But I think this part is a little poorly documented, I don't always trust the message sequence charts.

Reply
  • Alright, thank you. have to solve it differently then. I was thinking the SoftDevice has a buffer for a WRITE_REQ in which it keeps the data because it might need to resend it. so I thought it could as well deliver that data back to me when it creates the WRITE_RSP event. But maybe this data is deleted early so that the slot can be used again before the user has processed the WRITE_RSP event. (Well, and sending a new WRITE_REQ while handling this event would be a problem.)

    But I think this part is a little poorly documented, I don't always trust the message sequence charts.

Children
No Data
Related