Difficulties in connecting to BLE devices

[rsilva]

Hello,

I am using a BlueNRG-2 acting as a central to connect with multiple BLE devices, these devices can connect and disconnect multiple times.

I am using up to 6 simultaneous connections to different devices, after some successful attempts I keep getting errors from the ST API during the connection stage, usually at the pair/bonding stage.

The errors are either:

• BLE_STATUS_NOT_ALLOWED (0x46): no further information is available and I cannot understand why is this operation not allowed when calling 'aci_gap_send_pairing_req()'?
• BLE_STATUS_DEV_IN_BLACKLIST (0x59): how can I access and handle this blacklist, information on this is nonexistent, can I remove devices from the blacklist or prevent them from being stuck there?

When a connection fails the system seems to enter a loop and cannot recover.

Most commonly, what happens is that when there is an error, the initial connection is successful, but the process fails when negotiating at the encryption step (I am using default encryption with fixed pin).

I think this question might be similar to another posted to this forum but with no response so far, titled:

"STM32WB pairing error with mixed bonded/nonbonded devices

Thanks in advance.

[rcoel.1]

I have the same problem. Can someone help me?

[Javier1]

What are those "with multiple BLE devices"?

[rsilva]

Each of these Bluetooth devices is a tag device (category GAT 512).

The BlueNRG-2 is acting as a medium of communication with these devices (up to 6 simultaneously), currently the problems I report are happening on the BlueNRG-2 side when establishing a connection with the device.

[Sebastien DENOUAL]

Hi @rsilva​ ,

Let me comment about BLE_STATUS_DEV_IN_BLACKLIST.

This error could be raised while executing aci_gap_send_pairing_req and is defined inside BEL spec.

After multiple pairing failed from the same device (because of pin code error or any other reason), BLE specification define this concept of setting a device into BlackList. For security reason, this device is in blacklist and no pairing request will be possible for an initial delay of 20sec (timeout is increase at next paring failed request ).

About error : BLE_STATUS_NOT_ALLOWED, it means command is not correct because command is not call at right moment, because of wrong parameter.. .

Regards,

Sebastien.

[rsilva]

Hi @Sebastien DENOUAL​ thank you very much for your response.

Can you point me to any documentation on the BLE spec describing this blacklist process? I am not able to find any information on this.

Regarding the BLE_STATUS_NOT_ALLOWED, can this be a timing issue? a call to functions with a wrong parameter? or both?

Thanks in advance,

Rui

[Sebastien DENOUAL]

Hi @rsilva​ ,

The BlackList mecanism is known as "Repeated Attempts" (Feature Exchange) in BLE spec.

This is available in BLE spec (section 3.5.5 - in spec 5.2 )

 

Reason codes are described in table 3.7 :

 

Idea is to add this device in Blacklist until a timeout. The timeout for black list increases each time there is a failure, till a maximum of 135 seconds. After this period, you should be able to pair again.

Regarding the BLE_STATUS_NOT_ALLOWED, more difficult to conclude as many scenarios may lead to this error . Interesting here to understand if issue is 100% reproducible at 1st connection (means probably a parameter issue or bad order in commands). Is this happens only on multiple connections, but not 100% reproducible,... timing issue is one hypothesis among others.

Regards,

Sebastien

[rsilva]

Hi @Sebastien DENOUAL​,

thank you for the explanation.

Can you give some information about the timings involved in the repeated attempts feature?

What is the starting time interval, and how does this increase?

Best regards,

Rui

[Sebastien DENOUAL]

ok.. from my knowledge it starts from an initial delay of 20sec and increase up to 135sec in case of new failed attempts. Now, to be fully transparent I don't know how timeout value is incremented.

regards,

Sebastien.

[rsilva]

I appreciate your time, some information is better than no information, this already sheds some light on the process.

Best,

Rui