ota

RE: ota

AHaug — Thu, 04 Dec 2025 10:05:17 GMT

Hi Dede,

As previously mentioned I can't give you any examples since we don't have anything showcasing how OTA of remote devices are done with exception of the lwm2m exercise and the DFU Target mentioned by Hieu and the unofficial sample I sent you 30 days ago.

Kind regards,
Andreas

RE: ota

dede — Thu, 04 Dec 2025 09:15:42 GMT

Hi,

Thank you for your reply. I haven't solved the problem yet. Could you please give an example?

Thanks.

RE: ota

AHaug — Wed, 03 Dec 2025 13:31:51 GMT

Hi again,

I see Hieu has pointed you to the DFU Target in Nrf54l15 Manually perform firmware update . My bad for not mentioning this earlier. Let me know if this resolves the latest hurdle you were on.

[quote user="dede"] My idea is that the hub sends the firmware data of the mcuboot third version to the aura, the aura stores it in the mcuboot secondary, and then the terminal makes its own judgment based on certain conditions and performs the firmware upgrade. If possible, how can I add the judgment conditions?[/quote]

You can for instance read something in the image header or image trailer: https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/design.html#image_trailer to be able to determine where the image should be placed.

Kind regards,
Andreas

RE: ota

dede — Thu, 20 Nov 2025 08:21:47 GMT

Hi,

I can now write the firmware data to the mcuboot_secondary of the terminal, but I don't know how to implement the firmware update for the terminal.

Thanks.

RE: ota

dede — Thu, 20 Nov 2025 08:20:14 GMT

Hi,team,

I haven't solved this problem yet. Who can help me?

Thanks.

RE: ota

dede — Fri, 07 Nov 2025 07:25:30 GMT

Hi,

Thank you for your reply.
Because the terminal cannot establish a connection with the app to perform OTA (Over-The-Air Update), it can only communicate with the hub. I have now successfully implemented app splitting, and I have written the terminal's firmware into the mcuboot third area of the hub. So, is there such a custom Ota method? My idea is that the hub sends the firmware data of the mcuboot third version to the aura, the aura stores it in the mcuboot secondary, and then the terminal makes its own judgment based on certain conditions and performs the firmware upgrade. If possible, how can I add the judgment conditions?

Thanks.

RE: ota

AHaug — Tue, 04 Nov 2025 10:12:34 GMT

Hi,

[quote user="dede"]

I have created a flag. If the flag is 0x55AA5511, it means to update the hub because the firmware of the hub is defaultly downloaded to mcuboot_secondary. So I can easily implement the firmware update of the hub. If the flag is 0x55AA5522, it means to download the terminal firmware. But the problem is that I don't know how to download the firmware to mcuboot_third.

Do you know how to solve this problem?

[/quote]

The short answer is unfortunately no, I don't know this.

I did some more digging and found this unofficial sample that a colleague of mine made for NCS 2.4.0 https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/v2.6.0/bootloader_samples/client_smp/smp_client_ble. The implementation is hacky and you will have to do some patching, but hopefully it might be good enough to show case how to transfer data to a remote device. There's an issue if you attempt to transfer the candidate image in chunks to the remote if you call the transfer within an ISR. This sample shows how to do it in a workqueue.

It doesn't use sysbuild so this porting needs to be done as well.

I might have another sysbuild version that showcases how to do this in a thread context, but lets focus on the other one for now..

Kind regards,
Andreas

RE: ota

dede — Mon, 03 Nov 2025 03:08:47 GMT

Hi,

Thank you for your reply.
Your analysis is correct.

Do you know how to solve this problem?

Reference for the overwrite file is as follows:

app:
  address: 0x14800
  end_address: 0x177000
  region: flash_primary
  size: 0x162800
external_flash:
  address: 0x2C6000
  end_address: 0x7FF000
  region: external_flash
  size: 0x539000
external_flash_update_flag:
  address: 0x7FF000
  end_address: 0x800000
  region: external_flash
  size: 0x1000
littlefs_storage:
  address: 0x177000
  end_address: 0x17d000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x6000
mcuboot:
  address: 0x0
  end_address: 0x14000
  placement:
    align:
      end: 0x1000
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x14000
mcuboot_pad:
  address: 0x14000
  end_address: 0x14800
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x800
mcuboot_primary:
  address: 0x14000
  end_address: 0x177000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0x163000
  span: *id001
mcuboot_primary_app:
  address: 0x14800
  end_address: 0x177000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x162800
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x163000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0x163000
  
mcuboot_third:
  address: 0x163000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x2C6000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0x163000  

otp:
  address: 0xffd500
  end_address: 0xffd9fc
  region: otp
  size: 0x4fc
sram_primary:
  address: 0x20000000
  end_address: 0x2002f000
  region: sram_primary
  size: 0x2f000

Thanks.

RE: ota

AHaug — Fri, 31 Oct 2025 13:49:35 GMT

[quote user="dede"]How can the hub set secondary slot 1 and secondary slot 2 outside the flash? [/quote]

The hub doesn't per say "set this", but I'm guessing that you're asking about how to write the candidate image from the hub to the secondary slot of the remote device?

Let's break it down once more.

In your OTA hub you want to be able to do two things (w.r.t DFU): Update it's own firmare and update remote devices. This means that you either have to

Create a flag that separates if the candidate image in hub_mcuboot_secondary is for the hub or for the remote device (proprietary). If it's for the hub, then do DFU as normal and if it's for the remote then proceed with the routine you make for instance as described below
Have a storage partition for the remote device(s) and mcuboot_secondary is for only the candidate image to the hub.

After you've uploaded the image to the hub, the next thing you need to do is to connect to the remote. From there, you transfer the image using MCUMGRs img_mgnt to specify what to send to the remote. Depending on the solution above you need to take the contents of the candidate image slot in your hub and write to mcuboot_secondary on the remote. This is described in https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/cellular/lwm2m_client/fota_external_mcu.html

I'm sorry but we really don't have any implementations other than the lwm2m that shows how to update a remote device.

Kind regards,
Andreas

RE: ota

dede — Tue, 28 Oct 2025 06:22:34 GMT

Hi,

May I ask if there has been any progress on this issue?
My step is:
1. Implement the use of mcuboot_third to update the firmware of the hub, but currently I can only use the mcuboot_secondary of the off-chip flash to update the firmware of the hub.
2. Enable mcuboot to implement mcuboot_third using off-chip flash, which only stores the firmware without updating it. I speculate that perhaps modifying a certain logo word or firmware can achieve this function.
Overall, I still don't have any ideas at present. What should I do to achieve these two steps?

Thanks.

RE: ota

dede — Thu, 23 Oct 2025 11:34:49 GMT

Hi,

How can the hub set secondary slot 1 and secondary slot 2 outside the flash? Currently, the hub can only set secondary slot 1 and then perform its own update. However, I want to add another function: when receiving the firmware, download the terminal's firmware to secondary slot 2. How should I do this?

Thanks.

RE: ota

AHaug — Thu, 16 Oct 2025 08:08:54 GMT

Hi,

[quote user="dede"]The path is exactly as you described: mcuboot_third on the hub -> mcuboot_secondary on the external device -> mcuboot_primary on the external device. If there are any other simpler methods, they can also be tried.[/quote]

Noted, this is the recommended way. If you place it on the secondary on the external device, then the MCUboot bootloader on the external flash should know how to handle the candidate image given that you've uploaded the correct one. As soon as the image is in the external MCU's secondary application slot, then the external MCUBoot should go

[quote user="dede"]2. If the Ota solution for the terminal is feasible, then what should I do? However, you mentioned that this solution must be a proprietary one, which means the development process will be quite complex. Are there any other options? As long as the functions are achieved, it's fine: the terminal receives the firmware from the hub, and the terminal itself verifies and updates the firmware.[/quote]

I've spent some time looking around if we have any other options, and the answer is no, not for the specific use case that you have. We have a central to peripheral sample that you may be able to adapt, but note that this is a zephyr sample: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/central_smp_client/README.html in addition to the lwm2m sample.

Have you had a look at the central smp sample to see if there's a distribution feature that you can use from there?

Kind regards,
Andreas

RE: ota

dede — Thu, 09 Oct 2025 02:53:25 GMT

Hi,

1. Our custom app software will implement firmware updates by referring to the nrf connect tool. So when the nrf connect tool shows an error, it means that the custom app will also have the same error, which indicates that the firmware download for the device has failed.
The path is exactly as you described: mcuboot_third on the hub -> mcuboot_secondary on the external device -> mcuboot_primary on the external device. If there are any other simpler methods, they can also be tried.

2. If the Ota solution for the terminal is feasible, then what should I do? However, you mentioned that this solution must be a proprietary one, which means the development process will be quite complex. Are there any other options? As long as the functions are achieved, it's fine: the terminal receives the firmware from the hub, and the terminal itself verifies and updates the firmware.

Thanks.

RE: ota

AHaug — Mon, 06 Oct 2025 13:48:22 GMT

I think this sample sample where we've evaluated OTA of an external device through LwM2M may be helpful for you: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/cellular/lwm2m_client/README.html and https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/cellular/lwm2m_client/fota_external_mcu.html. The downside is that it doesn't show a use case for BLE OTA, but the application shows somewhat the same procedure that you describe.

[quote user=""]

Question 1.

I used the nrf connect firmware to download to the mcuboot_third area in the Hub, but the nrf connect tool reported an error.

[/quote]

Does the error affect anything other than affecting the status? Do you intend to go directly from mcuboot_third to the external MCU's MCUboot_primary slot? Or is the path:

mcuboot_third on hub -> mcuboot_secondary on external device -> mcuboot_primary on external device?

[quote user=""]Is the terminal's OTA solution feasible? Currently, the only way to perform firmware OTA for Aura is through the Hub. If not, how should I update the firmware for the terminal?[/quote]

The solution is feasible yes, but the solution has to be a proprietary solution since what we have that showcases OTA of an external device is only the lwm2m exercise above..

Kind regards,
Andreas