Device manager timeout handler and related event

[ppatierno]

Hi,

I'm using device manager for bonding starting from a sample application in the SDK.

I see that the DM_EVT_CONNECTION is raised before the BLE_GAP_EVT_CONNECTED but the dm event handler needs to start a timer for securing the link because it needs a valid m_conn_handle that is set only in the BLE_GAP_EVT_CONNECTED. Why these two events are raised in reverse order ? Can you explain me it better ?

I have this question because we are developing a board that haven't the externel oscillator for RTC1, so I can't use app timer and I need to remove the timer used to execute dm timeout handler. Is the only solution to use a TIMER1/2 or is there another solution to do that ?

Thanks, Paolo.

[Susheel Nuguru]

Hi ppatierno,

In most of our examples we did not have the dependency of the order in which the event_handlers for modules are called. If your example needs that m_conn_handle needs to be update in dm_event_handler then you can update it by just adding something like this

case DM_EVT_CONNECTION:
    m_conn_handle = p_event->event_param.p_gap_param->conn_handle;

The requirement of the order in examples is depending on particular use case.

or even change the order in which the event handlers are called inside ble_evt_dispatch

[ppatierno]

Thanks for the reply Aryan !

I started from ANCS example and the code is made in this way (you know it better than me) : dm_event_handler that starts timeout timer (in the DM_EVT_CONNECTION event) to setup the security on the link instead of execute it in the dm_event_handler itself.

Why ?

[Susheel Nuguru]

I see your point, The security setup was delayed by 1500ms (SECURITY_REQUEST_DELAY) and luckily the m_conn_handle was updated before the app_timer call back was called. This is a mistake (not a bug) in ANCS example but this but will never get triggered because m_conn_handle gets updated in time. Like I said, you can fix this by updating the m_conn_handle in DM_EVT_CONNECTION.

[ppatierno]

Just because I'm so curious but why in this example the security setup was delayed ? You said it's a mistake but IMHO setup a timer and execute security inside it seems to be an action that the developer wanted (not just a mistake).

[Susheel Nuguru]

it usually suggested to delay sending security request because we should allow the client to finish service discovery, I am actually not sure why this example has made it as a requirement, I will have to dig into it.

[ppatierno]

I lost this point ... it means that the service discovery starts and is executed before the link is secure ? If I avoid the delay and execute setup security without time what happens to the service discovery ?