cancel
Showing results for 
Search instead for 
Did you mean: 

BLE re-pairing is not possible.

ELEHM
Associate II

Hello.

I am developing a BLE HID device using the STM32CubeWB MCU Firmware Package, but when I try pairing => disconnect => pairing, pairing fails.

ELEHM_1-1718778784865.png

 

I have an implementation like this, is there a problem?
We have the following data in adv_data, which should not exceed 31 bytes (we have confirmed Success)

  • Appearance(3byte),Human Interface Device(3byte),swift pair(6byte),
    Local Name(9byte)

Also, if I put a breakpoint before aci_gap_update_adv_data, I can re-pair successfully. (I guess that means the timing of aci_gap_update_adv_data is NG?)

 

I would be grateful if you could give me an answer. Thank you.

1 ACCEPTED SOLUTION

Accepted Solutions
STTwo-32
ST Employee

Hello @ELEHM and welcome to the ST Community :smiling_face_with_smiling_eyes:.

From the context, we can see that there have been issues with the handling of bonding information and the updating of advertising data in the past. For instance, there was a mention of a problem where the second call to aci_gap_update_adv_data() always failed, returning an error code due to length data problems. 

Additionally, there was a discussion about the need to wait for a certain amount of time after receiving the EVT_DISCONN_COMPLETE event before turning off the STM32WB or performing certain operations to ensure that the bonding information is properly stored. So, I suggest you add a delay of more than 100ms after receiving the disconnection event before initiating any further actions.

So, I suggest you to:

  • Ensure that you are not calling aci_gap_update_adv_data too soon after a disconnection event. Introduce a delay, if necessary, as suggested in the context.
  • Verify that the total length of your advertising data does not exceed the 31-byte limit. Even though you have confirmed success, it's important to ensure that the data length is within the allowed limit after each update.
  • Check how the bonding information is being handled in your application. Make sure that the bonding data is properly stored and managed, especially after disconnection events.

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

2 REPLIES 2
STTwo-32
ST Employee

Hello @ELEHM and welcome to the ST Community :smiling_face_with_smiling_eyes:.

From the context, we can see that there have been issues with the handling of bonding information and the updating of advertising data in the past. For instance, there was a mention of a problem where the second call to aci_gap_update_adv_data() always failed, returning an error code due to length data problems. 

Additionally, there was a discussion about the need to wait for a certain amount of time after receiving the EVT_DISCONN_COMPLETE event before turning off the STM32WB or performing certain operations to ensure that the bonding information is properly stored. So, I suggest you add a delay of more than 100ms after receiving the disconnection event before initiating any further actions.

So, I suggest you to:

  • Ensure that you are not calling aci_gap_update_adv_data too soon after a disconnection event. Introduce a delay, if necessary, as suggested in the context.
  • Verify that the total length of your advertising data does not exceed the 31-byte limit. Even though you have confirmed success, it's important to ensure that the data length is within the allowed limit after each update.
  • Check how the bonding information is being handled in your application. Make sure that the bonding data is properly stored and managed, especially after disconnection events.

Best Regards.

STTwo-32

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello.@STTwo-32 

With your help, I was able to successfully pair a second time by adding a delay right after the disconnect event. (It's written in the API library, sorry I didn't look closely enough...)

Thank you very much!

Best Regards.