Detecting a BLE connection using 'm_conn_handle' issue

[PaulP]

Hi again, Hope everyone had a great Christmas.. I did, but Santa also gave me a litte issue with my nRF52-DK..

I using a modified UART example, I have a 5min repeating timer that set's a flag to call a '5minAction' sub from the main loop (works as expected) In the '5minAction' sub I start advertising, I then want to wait until a connection is established before transferring some data

err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
				APP_ERROR_CHECK(err_code);
		while(m_conn_handle == BLE_CONN_HANDLE_INVALID && connect_timout_secs < 40)
		{
			nrf_delay_ms(1000);
			connect_timout_secs++;
		}
	

However once I enter the loop testing for the connection it never exits the loop until the count down completes (I can see that normally I have a connection within a second (I can see my mobile says connected and a UART msg I send as a test from the ble_evt_handler - BLE_GAP_EVT_CONNECTED handler).

If I add a delay "nrf_delay_ms(20000) ;" between starting advertising and entering the loop, it see's it's connected on the first loop and exits as I would expect.

It seems that 'm_conn_handle' is not being updated whilst in this loop, I don't understand why, can anyone help?

[endnode]

Jesus Christ stop using bloody blocking calls like nrf_delay(xxx)!!! All FWs which uses BLE stack should be strictly asynchronous, no while or other waiting loops. Simply do what you need before entering main loop in the main() where you should only execute wait for event/interrupt and all the rest is handled as callback to your handler function supplied to Soft Device during initialization. Literally every BLE example in the SDK is written like that and it's not coincidence. So the best would probably be rewriting your application to fit this concept.

[endnode]

That's the problem: this kind of construction can work under some circumstances and if you settle with it then you will come into troubles sooner or later. And that looks like your problem. So my advise stays: never ever use nrf_delay or similar thing, not even for debugging, there are simple app_timer libraries or other tricks using RTC and TIMER to achieve the same in more elegant not blocking mode. And fix your FW design to work strictly in this way, then it's high chance that sequences like "start GAP Peripheral advertising => wait for incoming connection => act on event" will magically start working.