The NRF5 SDK supports the Bluetooth DFU SMP protocol.

[Frank]

hello,

  Our company has a product that uses the nrf5 SDK, with the main device using nrf52832 and the peripheral device using nrf52810. The main device upgrades the peripheral device through the Bluetooth DFU protocol.

  Currently, our peripheral device chip has been replaced with 54L05, using NCSv3.3.0. In order to be compatible with the previous main device, we need the nrf52832 nrf5 SDK to support the SMP upgrade protocol. Could you provide an example to assist us with our development?

Looking forward to your reply, thank you very much.

[Edvin]

Hello,

I am sorry, but we don't have support for the SMP protocol in the nRF5 SDK. Besides, the bootloaders are very different in the nRF5 SDK and in NCS, so you will not be able to DFU from nRF5 to NCS, if that was your plan.

However, if you want SMP support in the nRF5 SDK you would have to implement this yourself. It is not something we provide, unfortunately. But to be honest, I don't see why you would want/need that either.

Best regards,

Edvin

[Frank]

hello,

Thank you for your reply.

The need arises because the previous peripheral device using the 52810 chip has been replaced with the 54L05, while the main device remains the 52832. This main device needs to support both the new and old peripheral devices simultaneously.

I have an idea, could you help evaluate it,

whether the main device only needs to send the peripheral device's upgrade file to the slave device using the SMP protocol via Bluetooth.

[Edvin]

Hello Frank,

Please note that I will be out of office for a few weeks, starting in 7 hours, so for follow up questions, I will place your ticket back in the pool before I leave today, so it will be re-assigned to someone else if you have any more questions. 

Do you currently update the peripheral devices using the main device? How do you update the main device? Is it connected to internet in some way?

One workaround would be to update all devices using e.g. a mobile phone, or a computer that supports both the old and new protocol.

Another alternative is to update the main device to run NCS as well, but in this case, it will not be able to update the old peripherals. 

A third option is to implement a custom transfer protocol, similar to the one in the nRF5 SDk on NCS. The bootloader doesn't really care how the image is placed in the flash, as long as it is present before a reset. 

Have you tested DFU on the nRF54l05 in NCS? Do you have place for it on the internal flash, or do you have external flash as well?

BR,

Edvin

[Frank]

Hello Edvin,

Thank you for your reply.

There is an AP on the main device, and the AP connects to the network. The AP upgrades the main device through the serial port, and the AP can also send files of peripheral devices to the main device through the serial port.

54l05 We have verified the upgrade (using nrf connect app on the phone). 54l05 partition (mcuboot + slot1 + slot2), receive code in the app, mcuboot swaps the two partitions.

If a custom communication protocol is used, the 54l05 cannot use the existing SMP protocol. I believe that supporting the SMP protocol in the nRF5 SDK is the optimal solution, as it only needs to transmit to the 54l05 through the SMP protocol. Can you provide some examples of assistance for this solution?

Looking forward to your reply, thank you very much.

Frank

[Edvin]

Frank said:

Can you provide some examples of assistance for this solution?

Sorry, I can't do that. Implementing the SMP functionality is not a small task. It is not a trivial task, as this is not only a simple transfer protocol. 

Is the main device just an nRF52832 with an AP? Or is it connected to a larger system?

BR,
Edvin

[Edvin]

It seems feasible to implement this, but you need to do it yourself. I discussed this with AI, and it gave the following solution:

Fullscreen SMP_conv.txt Download

Below is a packet-level sequence for SMP over BLE (MCUmgr protocol) from nRF52832 (central/client) to nRF54L05 (peripheral/server running SMP svr + MCUboot).

SMP over BLE transport constants

SMP Service UUID: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
SMP Characteristic UUID: DA2E7828-FBCE-4E01-AE9E-261174997C48
Request transport: GATT Write Without Response to SMP characteristic
Response transport: GATT Notification from same characteristic
If SMP frame is larger than one ATT packet, fragment across multiple ATT packets in-order (no extra framing)
SMP header format (8 bytes, big-endian)

Byte 0: Res(2b)=0, Ver(2b), OP(3b)
Byte 1: Flags (0)
Bytes 2-3: Data Length (CBOR payload length)
Bytes 4-5: Group ID
Byte 6: Sequence number
Byte 7: Command ID
Common OP values used

Read request: OP=0
Write request: OP=2
Write response: OP=3
Read response: OP=1
Recommended end-to-end DFU sequence

BLE session setup

Connect to nRF54L05.

Exchange MTU (request max, use negotiated value).

Discover SMP service/characteristic.

Enable notifications (CCCD) on SMP characteristic.

Optional sanity ping:

Send OS Echo (Group 0, Cmd 0) or OS Params (Group 0, Cmd 6).
Confirm response seq matches request seq.
Pre-check image state

Send Image State Get:

Header: OP=0, Group=1, Cmd=0
CBOR: empty map {}
Parse response images list and existing hashes.

If target hash already active+confirmed, abort as already up-to-date.

Upload signed image (core transfer loop)

Compute SHA-256 of full signed bin on nRF52832 side before transfer.

First upload request:

Header: OP=2, Group=1, Cmd=1
CBOR map:
image: 0 (optional, default 0)
len: total_image_size_bytes (required on off=0)
off: 0
sha: 32-byte hash (recommended)
data: first chunk bytes
upgrade: true (optional, if you want version check)
Server upload response:

Header: OP=3, Group=1, Cmd=1
CBOR success includes off (next expected offset)
Continue loop:

For each next request send:
off: current_offset
data: chunk at that offset
Do not include len/image/sha except when off=0 restart is required.
Critical resume rule:

If server replies with off different from what you sent, treat server off as truth.
If server replies off=0 mid-session, resend first-packet fields again (len, sha, image, etc.) and restart from returned off logic.
Completion:

Upload is complete when returned off equals total image length.
If response includes match=false (when enabled on server), treat as verification failure.
Mark uploaded image for test boot

Send Image State Set (test):

Header: OP=2, Group=1, Cmd=0
CBOR:
hash: uploaded image hash
confirm: false
Validate response shows secondary slot pending.

Trigger reboot into new image

Send System Reset:

Header: OP=2, Group=0, Cmd=5
CBOR: {}
Expect short response, then link drop due to reboot.

Reconnect and post-boot verification

Reconnect BLE and re-enable notifications.

Send Image State Get (Group 1, Cmd 0).

Verify new image is active in slot 0.

Confirm image:

Preferred: nRF54L05 app self-confirms after health checks.
Or client confirms by Image State Set with confirm=true (with hash, or empty hash to confirm running image depending server behavior).
Final Image State Get should show active + confirmed.

Packet templates (logical SMP payloads)

Image upload request (Cmd 1)

First packet payload CBOR:
{
image: 0,
len: N,
off: 0,
sha: <32-byte binary>,
data: <chunk0>,
upgrade: true
}

Next packet payload CBOR:
{
off: X,
data: <chunkX>
}

Image upload response

Success:
{
off: NEXT_OFFSET
}

Error (SMP v1 style):
{
rc: <nonzero>,
rsn: <optional text>
}

Error (SMP v2 style):
{
err: { group: G, rc: R }
}

Image state set (test)

Payload:
{
hash: <32-byte binary hash>,
confirm: false
}

Image state set (confirm)

Payload option A:
{
hash: <running image hash>,
confirm: true
}

Payload option B (confirm running image):
{
confirm: true
}

nRF52832 implementation guidance (important for stability)

Keep one in-flight SMP request at a time (window=1 behavior).
Use Write Without Response but pace writes so one logical SMP frame is fully sent, then wait for notification response before next request.
Sequence number increments per SMP request and must match response.
Chunk size should be conservative:
ATT payload per fragment is MTU-3.
Keep total SMP frame size within server buffer constraints; if unknown, start small and increase carefully.
Use robust timeout/retry:
Retry same logical request on timeout.
Recover using server returned off.
Always upload signed bin produced for MCUboot update path.

This provides
nRF52832 can upload full image over BLE SMP and receives final off = image length.
nRF52832 can set test, reset, reconnect, and read image state.
nRF54L05 boots new app and ends in active+confirmed state.
Interrupted transfer resumes correctly using off/sha logic.

I suggest using an AI agent, to do a quick proof of concept, if you are starting this from scratch.

Best regards,

Edvin