BLE Advertisement Issue in nRF Connect SDK v2.7.0 (DRGN-23231) – Any Cherry-Pick or Temporary Fix Available?

[Prashant Humbre]

Hello Nordic team,

I'm currently developing on the nRF5340 and recently encountered an issue related to BLE advertisements. After thorough debugging, I was able to confirm that the root cause lies within the nRF Connect SDK, not within my application code.

While investigating further, I found that the issue is documented in the Known Issues section of the nRF Connect SDK v2.7.0 release notes with the ID: DRGN-23231
Reference: Known Issues - nRF Connect SDK

I also noticed that this issue appears to have been resolved in nRF Connect SDK v2.8.0.

Due to the fact that our product is already in production, a full migration to v2.8.0 will require additional time for integration and validation. In the meantime, I’m looking for a temporary resolution.

Could you please let me know:

• Is there a cherry-pickable commit or patch from v2.8.0 that can be applied to nRF Connect SDK v2.7.0 to temporarily resolve this issue?

• Or is there any recommended workaround that can be used until we complete the migration?

Any support or guidance would be highly appreciated, as we are aiming to resolve this issue as soon as possible in our production environment.

Thanks in advance!

Regards,

Prashant Humbre

[Vidar Berg]

Hello Prashant,

The fix for the mentioned issue was implemented in the Softdevice controller library so it can't be patched directly, unfortunately. But does this issue you are observing occur after you have been in a connection, or was it only advertising at the time? 

Thanks,

Vidar

[Prashant Humbre]

Hello Vidar,

Thank you for your quick response and for clarifying that the fix is part of the SoftDevice Controller library.

To answer your question, the issue I am observing occurs after a connection has been established.

In my particular scenario, this mainly occurs when the mobile phone goes out of range from the device during the DFU process while data is being transferred. After this happens, the device fails to resume advertising properly, and the only recovery option we’ve found so far is to power cycle the device, which is not ideal for a product that is already in production.

Additionally, after reviewing the Nordic debug logs, I observed that the Disconnect event is not getting triggered when the mobile phone goes out of range. This might be contributing to the issue, as the device seems to remain in an inconsistent state after the connection is lost abruptly.

If there are any mitigation steps, configuration changes, or temporary workarounds that I can apply while still on nRF Connect SDK v2.7.0, it would be very helpful until we can complete a full migration to v2.8.0.

Thanks again for your support!

Best regards,
Prashant

[Vidar Berg]

Hello Prashant,

Sorry it didn’t work. Did you make sure to set CONFIG_BT_BUF_CMD_TX_COUNT to a larger value than CONFIG_BT_BUF_ACL_RX_COUNT in the ipc_radio project? I realize that this requirement (i.e. CONFIG_BT_BUF_CMD_TX_COUNT >= CONFIG_BT_BUF_ACL_RX_COUNT + 1) was not made very clear in my previous response. Here is from the known issue descritption:

(commit: https://github.com/nrfconnect/sdk-nrf/pull/19869/commits/6c02a2b307297638bb92c18ccea514ea4326e71b)

Best regards,

Vidar

[Vidar Berg]

Update: in addition to what I suggested above, it may be necessary to increase the CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT setting in the IPC radio firmware to match this equation: 

(max_conn - 1) * MaxAttPacket + 1

, where MaxAttPacket is the maximum number of ATT packets your application will queue per connection.

The application must also ensure it does not queue more than "MaxAttPacket" per connection, especially when link quality drops in cases were a device is moving out of range. If the application is using GATT APIs with callbacks like bt_gatt_notify_cb, it can use the callbacks to monitor how many ATT packets are queued for each link.

For example, let's say your application needs to support 3 peripheral or central role connections, and each link should be allowed to queue up to 3 ATT packets:

(3 -1) * 3 +1 =7

So in this case, CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT should be set to 7. In the application, you must also ensure that no more than 3 write or notify packets are queued for a given connection at any time.

[Prashant Humbre]

Hi Vidar,

Thanks again for the clarification and example regarding CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT.

However, despite these changes, the issue still persists:

• On the first out-of-range event, a proper Disconnect event is received.

• On subsequent attempts, the Disconnect event is missing, and the device remains unresponsive until manually rebooted.

Please advise if there are any other diagnostics or logs I can share that might help — or if migration to v2.8.0 is the only practical resolution at this stage.

Best regards,
Prashant

[Vidar Berg]

Hi Prashant,

Prashant Humbre said:

On subsequent attempts, the Disconnect event is missing, and the device remains unresponsive until manually rebooted.

The fact that it only occurs on subsequent attempts (consistently I presume) is interesting and seems slightly different from the behaviour discussed in the other thread. However, it's maybe not surprising that the behavior differ given that these are totally different applications. 

Are you sending notification or write commands from the 'BT RX' thread (BT callbacks) or system workqueue by any any chance? If so, please try to offload that to another thread. Doing it from a BT callback at least can lead to deadlocks.

Best regards,

Vidar

[Prashant Humbre]

Apologies for the delay in responding.

I’ve now thoroughly tested all the changes, including the buffer configurations (CONFIG_BT_BUF_CMD_TX_COUNT, CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT)

Unfortunately, the issue still persists — the Disconnect event is only received on the first out-of-range event, and fails on the next attempt unless the device is power-cycled.

Yes, in my current implementation, GATT notifications are getting triggered during the DFU process, and it's possible they are being sent from within a Bluetooth callback or the system workqueue. I hadn’t considered this could lead to a deadlock or inconsistent state. I need to check this, I’ll report back shortly with the results.