GAP Disconnect seems to stop first application timer

[Ivan Herrera]

Using SDK 15.3 and S132.

I'm having similar behavior to the thread below:

https://devzone.nordicsemi.com/f/nordic-q-a/12066/gap-disconnect-stops-app-timer

After disconnecting with my nrf52 devkit, the conn_parameters module seems to stop my timer. If I disconnect from my nrf52 too fast (within 1 second of connecting), I get an error caused by 'update_timeout_handler' in ble_conn_params.c because it's trying to call 'send_update_request' after the disconnect has occurred. Unlike the OP in the other thread, I do in fact call conn_params_init(); at the start. Below my main() and conn_params_init(). I'm creating all my application timers by using APP_TIMER_DEF(). By debugging the code, I can see that the 'on_disconnect' function in ble_conn_params.c is stopping my application timer by calling 'app_timer_stop(p_instance->timer_id)'. Why does my application timer and the conn_params_timer have the same ID? 

/**@brief Function for application main entry.
 */
int main(void)
   {
    bool erase_bonds;

    // Initialize.
    log_init();
    // Initialize the async SVCI interface to bootloader before any interrupts are enabled.
    //ret_code_t err_code = ble_dfu_buttonless_async_svci_init();
    //APP_ERROR_CHECK(err_code);
    power_management_init();
    ble_stack_init();
    sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
    timers_init();
    application_timers_start();
    
    (void) fds_register(fds_evt_handler);
    ret_code_t rc;
    rc = fds_init();
    APP_ERROR_CHECK(rc);
    /* Wait for fds to initialize. */
    wait_for_fds_ready();
    
    //buttons_leds_init(&erase_bonds); 
    gap_params_init();
    gatt_init();
    services_init();
    conn_params_init();
    
    peer_manager_init();
    config_init();
    ...
    ...
    }

/**@brief Function for initializing the Connection Parameters module.
 */
static void conn_params_init(void)
{
    ret_code_t             err_code;
    ble_conn_params_init_t cp_init;

    memset(&cp_init, 0, sizeof(cp_init));

    cp_init.p_conn_params                  = NULL;
    cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
    cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
    cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
    cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
    cp_init.disconnect_on_fail             = false;
    cp_init.evt_handler                    = on_conn_params_evt;
    cp_init.error_handler                  = conn_params_error_handler;

    err_code = ble_conn_params_init(&cp_init);
    APP_ERROR_CHECK(err_code);
}

[Edvin]

Hello,

Why does my application timer and the conn_params_timer have the same ID? 

 Do they? How did you initialize them?

The ble_conn_params.c should use it's own instance of app_timers. It has one app_timer for every connection interval.

Is there some way for me to reproduce this on a DK?

Best regards,

Edvin

[Ivan Herrera]

No, you are correct. After some more debugging this is what seems to be happening.

1. I start my application timer

2. I connect to my DK. ble_conn_params starts a timer 'update_timeout_handler'. (p_instance->timer_id)

3. I disconnect within a couple seconds. ble_conn_params cancels p_instance->timer_id, but that now doesn't seem to be the original timer, but it seems to cancel one of my application timers? 

4. After another second, my application errors because the 'update_timeout_handler' wasn't properly cancelled -> tried to update parameters on an instance which had no running connection.

I will report back once I find out more

[Ivan Herrera]

After a little bit more of debugging I found out that initially the timers start out with different ID's, but that after starting and stopping several timers, the pointer of the conn_params_instance gets changed to either another timer (my application timer in this case), or by 0x00000000. This is caused by app_timer.c's 'timer_list_insert' function, which is modifying p_timer->next. Still figuring out why that is happening.

 

[Edvin]

Is there some way for me to reproduce this on an nRF52 DK?

[Ivan Herrera]

I'm just going to port everything to the latest SDK and verify all the code. I'll let you know if the issue persists.