WICED Smart Bluetooth

[Anonymous]

Often when central attempts to connect (connUp) with peripheral,

central serial port shows ""bleprofile_connDown stop Idle Timer"", and then it gets a connDown callback, but no connUp callback.

[MichaelF_56]

Hi Doug,

I wanted to let you know that we are looking into this issue (based on the first post) and will get back to you shortly with some feedback.

[Anonymous]

Thanks, m.

As a workaround, central now detects this condition, and immediately again attempts to start connection (connUp) again.  Sometimes, each connection attempt results in immediate connDown, but eventually there is connection and connUp callback.

[Anonymous]

Any news on this problem?  This is our only major issue with the Bluetooth communication.

[VictorZ_46]

Try to call emconinfo_getDiscReason, it might give you some clues as to why connection is going down.  In LE when central tries to establish connection it some times can get a connection up notification although connection has not been established completely.  That might be the cause of connection down callback being called.  Following is a quote from BT spec.

2.59 CONNECTION FAILED TO BE ESTABLISHED (0x3E)

The Connection Failed to be Established error code indicates that the LL initiated

a connection but the connection has failed to be established.

[Anonymous]

Will do.

Does emconinfo_getDiscReason() print the reason, or return something?

[Anonymous]

I tried it, but get no result.

Here is list of ble functions called, and ble output:......

S T A R T S C A N :

blecm_CreateConnectionCancel();

blecm_CreateConnection(

  blecen_cen_cfg.high_scan_interval,

  blecen_cen_cfg.high_scan_window,

  blecen_cen_cfg.init_filter_policy,

  peer_addr_type,

  (char *)peer_addr,

  blecen_cen_cfg.init_addr_type,

  blecen_cen_cfg.high_conn_min_interval,

  blecen_cen_cfg.high_conn_max_interval,

  blecen_cen_cfg.high_conn_latency,

  blecen_cen_cfg.high_supervision_timeout,

  blecen_cen_cfg.conn_min_event_len,

  blecen_cen_cfg.conn_max_event_len

  );

　

　

bleprofile_connUp()

BLE_no_adv

C A L L B A C K  F O R     C O N N U P    O C C U R   S H E R E ...

smp timer started 01

smp conn down

smp timer stopped

bleprofile_connDown()

bleprofile_connDown stop Idle Timer

　

　

>>>  U N E X P E C T E D   C A L L   B A C K   FOR CONNDOWN   OCCURS HERE : ... <<<

emconinfo_getDiscReason() is now called, but doesn't do anything.

[ArvindS_76]

What does emconinfo_getDiscReason() return?

[Anonymous]

disc_reason is always 3e.

HERE IS DEBUG OUTPUT:

control_peripheral_connection( adr=1 )

- Start high speed connection with 1.

00:04:00 PWR RX comm: 13933=P1 0=P2 0=P3 

bleprofile_connUp()

BLE_no_adv

　

callback_connection_start() #496 rtt(2)

peripheral's address=000000000001 hand=64

smp timer started 01

smp conn down

smp timer stopped

bleprofile_connDown()

bleprofile_connDown stop Idle Timer

　

callback_connection_end() #496

connection_start_FAULT 91 <<<<<<<<<<<

Disc_Reason: 3e

control_peripheral_connection( adr=1 )

- Start high speed connection with 1.

bleprofile_connUp()

BLE_no_adv

　

callback_connection_start() #497 rtt(2)

peripheral's address=000000000001 hand=64

smp timer started 01

smp conn down

smp timer stopped

bleprofile_connDown()

bleprofile_connDown stop Idle Timer

　

callback_connection_end() #497

Disc_Reason: 3e

control_peripheral_connection( adr=1 )

- Start high speed connection with 1.

bleprofile_connUp()

BLE_no_adv

　

callback_connection_start() #498 rtt(2)

peripheral's address=000000000001 hand=64

smp timer started 01

smp conn down

smp timer stopped

bleprofile_connDown()

bleprofile_connDown stop Idle Timer

　

callback_connection_end() #498

Disc_Reason: 3e

control_peripheral_connection( adr=1 )

- Start high speed connection with 1.

bleprofile_connUp()

BLE_no_adv

　

callback_connection_start() #499 rtt(2)

peripheral's address=000000000001 hand=64

smp timer started 01

smp timer refresh

smp timer refresh

smp timer stopped

callback_encryption_changed() #137

callback_connection_bond() #137

[MichaelF_56]

I seem to recall a previous response from the SW team explaining that if you receive 0x3e back during connection establishment, that you need to retry.

[Anonymous]

Oh, ok.  So it is normal -- perhaps caused by local RF 'conditions'?

Is it safe to again attempt connection (start connUp) from inside the connDown callback?

Or is it safer to wait a little, and attempt again from with the fine timer callback?

[MichaelF_56]

I checked with the developers and there shouldn’t be a problem attempting a new connection (start connUp) from inside the connDown callback.  In fact, they said either method should be fine.

[Anonymous]

Thanks.

We get multiple of those 3e errors per minute.

Is that normal Or a problem?

[VictorZ_46 · Accepted solution]

If you have an WiFi Access Point nearby sending high traffic on one of the advertisement channels it is indeed quite possible.