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

Missed GATTC Write Response

Hello,

I'm using the nRF52 DK with SDK 15 and SD132 6.1.0. I have a custom service running that requires periodic characteristic writes. Occasionally when writing to this characteristic, sd_ble_gattc_write returns 0x11 (NRF_ERROR_BUSY). When this happens the application attempts to rewrite the characteristic, but after that all future writes return NRF_ERROR_BUSY. While debugging, I noticed that the device did not receive a write response which is preventing any other writes from happening. 

It appears that the reason I'm missing the write response has to do with scanning. If I do not re-enable scanning after establishing a connection the device works as expected, but I need to re-enable scanning to connect to other peripheral devices.

I have a few questions relating to the above behavior:

  1. If the scanning window is sufficiently large is it possible to miss the write response? (Current scan window 80 * 0.625 ms)
  2. Is there a way to get scanning and characteristic writes to co-exist without issue?
  3. Is there a way to abort the write so that the application can recover if this does happen?

Thanks in advance,

Eric

Parents
  • Q1: What kind of connection interval are you using? How many connections is running concurrently? If the scan window is much larger than the connection interval, then some connection events may be dropped, see S132 SDS v6.1 Chapter 15.4.1 Primary channel scanner timing. 

    Q2: The SoftDevice scheduler will schedule the connection events before the scanner events as shown in the above screenshot from the S132 v6.1 PS. Given that the scan window is not to long.

    Q3: No, if the peer never replies to the Write Request, then the BLE_GATTC_EVT_TIMEOUT event will be generated and the link is considered lost and reconnection is required. 

    Best regards

    Bjørn

Reply
  • Q1: What kind of connection interval are you using? How many connections is running concurrently? If the scan window is much larger than the connection interval, then some connection events may be dropped, see S132 SDS v6.1 Chapter 15.4.1 Primary channel scanner timing. 

    Q2: The SoftDevice scheduler will schedule the connection events before the scanner events as shown in the above screenshot from the S132 v6.1 PS. Given that the scan window is not to long.

    Q3: No, if the peer never replies to the Write Request, then the BLE_GATTC_EVT_TIMEOUT event will be generated and the link is considered lost and reconnection is required. 

    Best regards

    Bjørn

Children
Related