Firmware upgrade failed issue over BLE

[Mansi Singh]

Hi,

I’m working on an nRF5340 using nRF Connect SDK v2.7.99-cs2.
BLE security is configured as Just Works (Security Mode 1, Level 2) on the peripheral.

I’m attempting firmware upgrade over BLE, but the upgrade is failing due to what looks like message ordering between the peripheral and the central:

• On the peripheral (firmware logs):
  I see Response = 1 (Start of Frame) → Data → Response = 0 (End of Frame).
  This is the expected sequence.

• On the central (peer device logs):
  The observed order is Response = 1 → Response = 0 → Data, which arrives out of order, causing the FUS to fail.

I also suspected thread scheduling. Although BLE thread priorities aren’t directly configurable, I reduced other thread priorities higher than BLE and keep the following as it is:

CONFIG_BT_RX_PRIO=8

CONFIG_BT_HCI_TX_PRIO=7

CONFIG_BT_DRIVER_RX_HIGH_PRIO=6

CONFIG_SYSTEM_WORKQUEUE_PRIORITY=-1

So what could be the possible root cause of this behavior?

[Vidar Berg]

Hi,

I’m attempting firmware upgrade over BLE, but the upgrade is failing due to what looks like message ordering between the peripheral and the central:

What messages are you referring to in this context? Are you using a proprietary DFU protocol, or SMP (supported by our nRF connect and nRF devices manager apps)?

On the central (peer device logs):
The observed order is Response = 1 → Response = 0 → Data, which arrives out of order, causing the FUS to fail.

Are you able to provide actual logs? What does FUS stand for?

I also suspected thread scheduling. Although BLE thread priorities aren’t directly configurable, I reduced other thread priorities higher than BLE and keep the following as it is:

I recommend you keep these configs as is. It is not likely to be related to the DFU issue.

Best regards,

Vidar

[Mansi Singh]

• FUS is being used for firmware upgrade services.

• Debug logs have been enabled on both the device and the central (peer) device.
  However, the sequence of logs captured on both sides does not match.

  Device-side debug log sequence:

  • Response = 1 (indicating start of frame)
  • Data
  • Response = 0 (indicating end of frame)

  Central (peer device) debug log sequence:

  • Response = 1
  • Response = 0
  • Data

• BLE configuration settings have been kept unchanged.

[Vidar Berg]

I don't know what "FUS" refers to or which DFU protocol you are using. I was hoping the logs might provide additional context.

[Mansi Singh]

Hi, 

As I have mentioned already FUS stands for Firmware Upgrade Services and about DFU that is in-house one. What exactly informations you want please let me know.

[Vidar Berg]

Hi,

Thanks for confirming that this is a proprietary DFU protocol. Since I do not know anything about your implementation it is difficult to speculate about what the issue might be. But I can say that Bluetooth packets do not arrive out of order, the way bluetooth works prevents that. The stack thread priorities are not meant to be changed. If you want to validate what is being received and sent by the link layer, you can capture a HCI packet trace from the nRF5340 using https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/hci_logger.html or sniff the packets on air.