Proper S110 cleanup on link loss/disconnect?

[Mike Wirth]

Folks, Here's a specific question and a larger question, of which the first is a part.

1. What's the proper way to insure S110 BLE stack cleanup on disconnect due to link loss, especially so I can quickly restart advertising to reestablish the connection?

2. Is there a document on "link management", i.e., handling link connections, reconnection attempts, possible peer error states, with or without bonding, etc., to try to keep two devices connected in as robust a way as possible?

Context: I'm using the S110 stack, version 5.1 on an nRF51822 (production version C0, IIRC) and SDK 4.4.2 (limited to this version by the IC prod. version). BTW, tried the version 6.0 stack but failed (probably because I didn't go through the migration instructions). Communicating with an iPhone 5, running iOS 7.1 and the current Core Bluetooth framework.

Problem: When the connection is running stably for awhile, I cause a disconnect (either by moving out of range or by killing the iPhone app). S110 senses disconnect and issues BLE_GAP_EVT_DISCONNECTED event, which my app picks up and sets the saved connection handle variable to BLE_CONN_HANDLE_INVALID. I use this to realize that I'm no longer connected and attempt to go back into advertising mode by regenerating the advertising params structure and calling sd_ble_gap_adv_start again. But it fails with error 8: "NRF_ERROR_INVALID_STATE Invalid state, operation disallowed in this state". So I'm clearly missing some cleanup step.

I've tried making sure the app-task/event queue is empty by running app_sched_execute() before starting advertising again, delaying 1 sec. to give the stack time to settle, both to no avail. BTW, is there an easy way to inquire as to the current state of the stack? I must have missed it.

Any comments and help appreciated,

Mike

[Pål Håland]

Hi Mike, Just a small comment. Do you have a different flag to disallow calling the sd_ble_gap_adv_start twice right after each other? It looks like you have only one flag to determine if you should start advertising again, and this flag will not be updated until you have a connection. In the connection event.

It would probably be an idea to have a BLE_CONN_HANDLE_INVALID and BLE_CONN_HANDLE_ADV_STARTED or something, and only trigger advertising on the BLE_CONN_HANDLE_INVALID, and then update it to BLE_CONN_HANDLE_ADV_STARTED?

BR Pål