Aci_gap_set_discoverable() returns Command Disallowed after long period of execution (100+ connections, wakeups and advertisements)

[Mathieu Wernsen]

I've been experiencing an issue where sporadically the aci_gap_set_discoverable fails to start due to a command disallowed error (similiar to this) on the STM32WB50.

For context: the device goes into sleep mode and wakes-up 100+ times per day. In sleep mode the device advertises in low power mode (min: 546.25ms, max 760 ms). When woken it will advertise in fast mode (min: 20 ms, max 25ms). These parameters perform well.

Before going to sleep mode all active connections are disconnected and this is verified by checking all the link statuses using aci_hal_get_link_status. Once every so many days the device will run into an error that it can't start advertising even though all links appear to be non-active and the advertising parameters are correct.

What additional steps can I take to debug this problem?

FYI, the device is running STM32CubeWB 1.15.0

[Remy ISSALYS]

Hello,

Aci_gap_set_discoverable function can return the error code Command Disallowed if an advertising is already running or if the advertising parameters are wrong. When your device is in fast advertising mode, do you reestablish the previous connection or not?

Best Regards

[Mathieu Wernsen]

Hi Remy,

Thanks for the response. The Aci_gap_set_discoverable returns without error codes. After waking up the device will most likely reestablish connection with the same master as before, but it can also be a different master.

I did some more investigating and it appears a BLE link of the CPU 2 get stuck when disconnecting the masters (aci_gap_terminate). The following sequence is in place:

1. System wakup: Do all standard BLE initialization and start fast advertising. (aci_gap_set_discoverable)
2. First master connects. Handle hci_le_connection_complete_event_ and restart advertising in fast mode for second master to connect.
3. Second master might or might not connect. Assume for now it does not and therefore advertising stays active.
4. System goes to sleep mode: Stop advertising (aci_gap_set_non_discoverable), and break connection with possible masters (aci_gap_terminate). Start advertising in low power mode.

The interesting part is that once every so many times the aci_gap_terminate command will not result in a hci_disconnection_complete_event and the link disconnecting. Using a BLE sniffer I can see that no packets are sent between master and slave at this point and connection from master side disconnects after supervision timeout has passed.

Additional calls to aci_gap_terminate does not appear to close/terminate the link. I'm validating connection handle and link status using the aci_hal_get_link_status command.Currently I'm resetting the device as soon as I detect this "stuck" link, however this is not very optimal.

Lastly, this behavior does not appear to happen when skipping the fast advertising step in step 2 from the list above.

Best Regards,

Mathieu

[Mathieu Wernsen]

I accidentally left my reply as a new answer. Please see my message below.

[Remy ISSALYS]

Hello,

Did you reproduce this issue if you stay in run mode?

Best Regards

[Mathieu Wernsen]

Yes. My testing loop to debug this issues skips the whole sleep cycle so:

1. System wakup.
2. Fast advertising, connect master 1, restart fast advertising
3. Delay while staying in Run mode (5 s)
4. Set to non-discoverable, terminate connections, low power advertising
5. Delay while staying in Run mode (3s)
6. Start again from step 2.

[Mathieu Wernsen]

In the end I've decided to simply do a full reset of the hci stack (hci_reset) before going to sleep to make sure none of the links remain in locked condition.