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]

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.