Detecting a BLE connection using 'm_conn_handle' issue

RE: Detecting a BLE connection using 'm_conn_handle' issue

endnode — Thu, 28 Dec 2017 11:24:26 GMT

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.

RE: Detecting a BLE connection using 'm_conn_handle' issue

PaulP — Thu, 28 Dec 2017 00:51:33 GMT

I only have that sort of loop in the one place(it was intended as a quick test), the rest uses interrupts, what was confusing me was that I could see other stuff happening outside the loop... i.e. serial transmission etc.

RE: Detecting a BLE connection using 'm_conn_handle' issue

endnode — Wed, 27 Dec 2017 22:55:25 GMT

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.