unexpected "bleprofile_connDown stop Idle Timer"

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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.

1 Solution

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

View solution in original post

0 Likes
13 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

0 Likes

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
Not applicable

Will do.

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

0 Likes
Anonymous
Not applicable

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.

0 Likes

What does emconinfo_getDiscReason() return?

0 Likes
Anonymous
Not applicable

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

0 Likes

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.

0 Likes
Anonymous
Not applicable

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?

0 Likes

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.

0 Likes
Anonymous
Not applicable

Thanks.

We get multiple of those 3e errors per minute.

Is that normal Or a problem?

0 Likes

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

0 Likes