Firmware upgrade failed issue over BLE

RE: Firmware upgrade failed issue over BLE

Vidar Berg — Thu, 26 Feb 2026 06:41:57 GMT

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.

RE: Firmware upgrade failed issue over BLE

Mansi Singh — Thu, 26 Feb 2026 05:52:16 GMT

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.

RE: Firmware upgrade failed issue over BLE

Vidar Berg — Wed, 25 Feb 2026 15:56:00 GMT

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

RE: Firmware upgrade failed issue over BLE

Mansi Singh — Wed, 25 Feb 2026 15:01:54 GMT

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.

RE: Firmware upgrade failed issue over BLE

Vidar Berg — Wed, 18 Feb 2026 08:56:34 GMT

Hi,

[quote user=""]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:[/quote]

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)?

[quote user=""]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.[/quote]

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

[quote user=""]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:[/quote]

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

Best regards,

Vidar