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

[Mike Wirth]

Just to follow up and close this question: Problem solved. Pål was on the right track. I wasn't making a redundant call to start advertising, but after the new connection was established I was attempting to restart RSSI-changed events and the call was failing because it was already started (didn't get shutdown when the prior connection went away and survived through the disconnect and reconnect).

At this point, I would make a plea for a general "feature" in the S110 Soft Device -- it would be great to have a way to ascertain the current state of the BLE stack. In particular, any configuration change that's written to the soft device should be readable.

In the current case, if I ask to start RSSI-changed events, at some other point in my code it would be great to be able to determine the state of this activity. Without that, I had to write test code to determine that the call to start it while already running failed, but redundant calls to stop it didn't. Therefore, a defensive programming style is to always turn the activity off before starting it up. Seems kind of silly.

Thanks again,

Mike