cancel
Showing results for 
Search instead for 
Did you mean: 

Smart Bluetooth

Anonymous
Not applicable

My understanding is the connection timeout error is supposed to happen

after supervision timeout which is 500 ms in my application.

The problem is scan no longer works once the connection timeout (0x8) occurs.

My application is the Initiator of the connection and

emconinfo_getDiscReason() returns 0x8 on connection down callback.

Can you provide some advice to debug this issue?

I am using 20737 with SDK 2.1.1

Here are my scan parameters.

blecen_cen_cfg.scan_type = HCIULP_PASSIVE_SCAN;

    blecen_cen_cfg.scan_adr_type = HCIULP_PUBLIC_ADDRESS;

    blecen_cen_cfg.scan_filter_policy = HCIULP_SCAN_FILTER_POLICY_WHITE_LIST_NOT_USED;

    blecen_cen_cfg.filter_duplicates = HCIULP_SCAN_DUPLICATE_FILTER_OFF;

    blecen_cen_cfg.init_filter_policy = HCIULP_INITIATOR_FILTER_POLICY_WHITE_LIST_NOT_USED;

    blecen_cen_cfg.init_addr_type = HCIULP_PUBLIC_ADDRESS;

blecen_cen_cfg.high_scan_interval = 1500; //slots

    blecen_cen_cfg.low_scan_interval = 1500; //slots

    blecen_cen_cfg.high_scan_window = 100; //slots

    blecen_cen_cfg.low_scan_window = 100; //slots

    blecen_cen_cfg.high_scan_duration = 300; //seconds

    blecen_cen_cfg.low_scan_duration = 300; //seconds 

blecen_cen_cfg.high_conn_min_interval = 8;  //frames

    blecen_cen_cfg.low_conn_min_interval = 8;  //frames

    blecen_cen_cfg.high_conn_max_interval = 8; //frames

    blecen_cen_cfg.low_conn_max_interval = 8; //frames

blecen_cen_cfg.high_conn_latency = 0;

    blecen_cen_cfg.low_conn_latency = 0;

    blecen_cen_cfg.high_supervision_timeout = 50;

    blecen_cen_cfg.low_supervision_timeout = 50;

    blecen_cen_cfg.conn_min_event_len = 0;

    blecen_cen_cfg.conn_max_event_len = 0;

0 Likes
1 Solution
Anonymous
Not applicable

Hi Hardy,

Thanks for your help. I think it is really worth trying your suggestion.

By the way, the connection timeout (0x8) is no longer observed after switching to our newly designed board.

Therefore, this issue is not reproducible any longer.

Perhaps it was triggered by some board related issues or instability of hardware?

View solution in original post

6 Replies
Anonymous
Not applicable

Found the following codes from a4wp_power_transmitter sample app.

if (emconinfo_getDiscReason() == BLEPTUM_HCI_ERR_CONNECTION_TIMEOUT)
{

#ifdef BLEPTUM_HCI_RESET

    if(bleprofile_p_cfg->disc_required & BLEPTUM_HCI_RESET)
    {
        blecm_hciReset();
        ble_trace0("HCI_Reset");
    }

#endif

#ifdef BLEPTUM_WDTO

    if (bleprofile_p_cfg->disc_required & BLEPTUM_WDTO)
    {
        ble_trace0("Watchdog_timeout");
        // infinite loop to trigger WD reset
        while(1);
    }

#endif

}

Is it recommended to do HCI reset or Watchdog reset on Connection Timeout?

0 Likes
MiTo_1583836
Contributor II

Are you powering off the slave right after the connection to get to the timeout?

I would try to call: blecm_disconnect(BT_ERROR_CODE_CONNECTION_TERMINATED_BY_LOCAL_HOST); when you receive the link down callback. I may help to clear a state in the stack.

Anonymous
Not applicable

Hi 79rpm,

Thanks for your advice.

I am getting the connection timeout in Master while receiving Notification data from Slave.

According to BLE sniffer trace, Master suddenly stops sending POLL frame (header only) to Slave.

Notification data interval is 10 ms in my use case.

Just tried blecm_disconnect() as you suggested, the scan issue still occurs.

0 Likes
Anonymous
Not applicable

79rpm

A similar symptom of the fatal error has been observed after LMP RESPONSE TIMEOUT (0X22).

Is there any to work around this issue? Or anyway to reduce the chance of this error?

0 Likes
hachc_2137126
Contributor II

Hi mkim,

  Not sure about the reason of your case, but would you try to have kind of reset state machine as posted here Problem when client disconnection during Indication/confirmation phase. ?

Anonymous
Not applicable

Hi Hardy,

Thanks for your help. I think it is really worth trying your suggestion.

By the way, the connection timeout (0x8) is no longer observed after switching to our newly designed board.

Therefore, this issue is not reproducible any longer.

Perhaps it was triggered by some board related issues or instability of hardware?

View solution in original post