sd_ble_gap_disconnect returns 0x08, BLE_GAP_EVT_DISCONNECTED never arrives, further attempts to disconnect fail, unable to reconnect - advertising stops.

Hey

I am working on nRF51822 SDK12, S130

I have encountered a problem when connecting and disconnecting from the device at a fast rate, occasionally comes an event in which the sd_ble_gap_disconnect() command fails (the error received is 0x08.), the BLE_GAP_EVT_DISCONNECTED never arrives, the device stops advertising and no longer available to reconnection. the device is gone. 

I have tried to disconnect again after a small interval, that does not help.

I have tried to wait for a long time for the BLE_GAP_EVT_DISCONNECTED to arrive, it never arrives.

I have tried to set m_conn_handle = BLE_CONN_HANDLE_INVALID as seen in some thread on the forum. that doesn't help.

nothing works 

Any advice will be much appreciated

Thanks!

Parents
  • Hi,

    Can you add debugging to ensure that if BLE_GAP_EVT_DISCONNECTED event occurs for instance before sd_ble_gap_disconnect() is called, then it is handled already. Error code 8 means: 

    Disconnection in progress or link has not been established.

    So either you have already disconnected (BLE_GAP_EVT_DISCONNECTED already occurred), or that you are calling sd_ble_gap_disconnect() before BLE_GAP_EVT_CONNECTED event has occurred. I can't really think of any other suggestion as long as the conn_handle is valid.

    Best regards,
    Kenneth

  • Hey, I also want to note that the conn_handle is 0 when this error occurs.

    Thanks

  • Ron said:
    The central definitely might disconnects before I have disconnected actively, can it be that the soft-device considered the link to be Disconnected before issuing the event?

    That may happen yes, you should however receive the disconnect event at some time.

    Best regards,
    Kenneth

  • Hey Kenneth,

    Unfortunately I don't receive the disconnect event, 

    I suspect that I attempt to disconnect manually while the central has turned off (I just turn it off, not disconnecting) in parallel and that causes some kind of problem with the softdevice because I definitely do check for the events before I disconnect on peripheral side.

    The only action that seems to get the peripheral out of this state in which it regards itself as connected while infact isn't and not advertising is to reset , I would like to reset the softdevice alone, to reset the BLE, is there a way to do this?

    I have tried to call sd_softdevice_disable() and than ble_stack_init() but for some reason after a few seconds I get an error ("softdevice_Fault_handler is called)

    Thanks!

  • Which softdevice version is this of the S130? I can check for known issues.

    Best regards,
    Kenneth

  • Hi Kenneth

    As I said, I have tried to restart the BLE which seems to cause a chip reset, I have seen that the reset to the chip does not occur if I do not initialize my ADC-PPI,

    I have seen in a different Thread a similar issue being raised and the solution was lowering the priority of the ADC interrupt, in my case it is the lowest, so note that does not seem to solve my problem

    Thanks again

  • Hey Kenneth

    An Update regarding the softdevice reset issue, I found out what was missing in my Reinitialization, Now I Reinitialize the softdevice properly and it seems to work, so I just reset the softdevice whenever the disconnect command fails, still, this is not optimal and I would like to know why it fails to begin with (and prevent it ofcourse)

    Thank you

Reply
  • Hey Kenneth

    An Update regarding the softdevice reset issue, I found out what was missing in my Reinitialization, Now I Reinitialize the softdevice properly and it seems to work, so I just reset the softdevice whenever the disconnect command fails, still, this is not optimal and I would like to know why it fails to begin with (and prevent it ofcourse)

    Thank you

Children
  • I can't any issue that may cause the disconnect event does occur, the only thing is that the BLE_GAP_EVT_DISCONNECTED event may be very delayed, e.g. until supervisor timeout occurs on the link. But it should still occur, so if you want us to look into this in more detail I am afraid we need an on-air sniffer log of the situation and/or a way to recreate it here (e.g. you provide firmware for this kits we may run).

    Best regards,
    Kenneth

Related