CPU stays active before disconnect event

[Andrej]

hello,

first i use the nrf mesh sdk 4.2.0, nrf52 DK board and light_switch_server_example with small modifications for debug purpose .

I noticed that when i connected to the board via nrf Connect App and disconnect again the cpu stays active for about 155ms before the BLE_GAP_EVT_DISCONNECTED raises.

The yellow signal only shows the connection state  so on BLE_GAP_EVT_CONNECTED it goes high and on BLE_GAP_EVT_DISCONNECTED low.

Red signal is the current consumption with debugger connected and running ( Segger J-Link with Isolator -> Offset of about 4mA)

This behavior is only visible if mesh is used / in mesh sdk 5.0.0 (same behavoir)

But i can't find the source of this issue by myself. Please help me

Best regards 

Andrej

[Hung Bui]

Hi Andrej, 

I tested here and can confirm that the CPU is active for a period of time (130-150ms) AFTER the disconnect event occurred. 

Please have a look at my screenshot: 

You can find the pin toggled before the CPU is active. (I clear the pin in BLE_GAP_EVT_DISCONNECTED event)

I don't have exact answer for what the CPU is doing in such period, but I can find a state machine (FSM) used in nrf_mesh_prov_bearer_gatt.c that's executed after the disconnected event occurs. There could be a flash activity after the disconnection. 
But this only happens when the device has not provisioned. If the device is provisioned and running as a proxy node you don't have this CPU active period when you connect&disconnect. 

This can be consider normal mesh operation and I don't think it would affect the power consumption of the device in its life time. 

[Andrej]

Hi,

thank you for your fast reply...now i can search for the root of this "issue" ... normally nothing has changed and no flash operation should be invoked. I hope in future releases of the mesh sdk it will be fixed.

I will write again if i find the root.

[Andrej]

if i comment out nrf_mesh_prov_bearer_gatt.c / a_link_close_notify / closed  callback there is no 150ms cpu activity visible 

static void a_link_close_notify(void * p_context)
{
    fsm_evt_gatt_data_t * p_evt = p_context;
    timer_sch_abort(&p_evt->p_bearer_gatt->link_timeout_event);
    p_evt->p_bearer_gatt->bearer.p_callbacks->closed(&p_evt->p_bearer_gatt->bearer, NRF_MESH_PROV_LINK_CLOSE_REASON_ERROR); //if commented out, no extra power is drawn
}

if i step through the code i found out that the provisionee_start is called in mesh_provisionee.c after a disconnect and the uECC is generating new keys.

[Andrej]

I found a solution for me... i stop the scanner before nrf_mesh_prov_generate_keys and start it again.

positiv effect: lower power consumption

negativ effect: scanning is inactiv for 150ms