Skip to main content
Associate II
June 19, 2024
Solved

BLE re-pairing is not possible.

  • June 19, 2024
  • 2 replies
  • 1190 views

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.

This topic has been closed for replies.
Best answer by STTwo-32

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

2 replies

STTwo-32
STTwo-32Best answer
ST Technical Moderator
June 19, 2024

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.
ELEHMAuthor
Associate II
June 20, 2024

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.