Modularisation of a firmware

RE: Modularisation of a firmware

Menon — Tue, 02 Dec 2025 15:59:24 GMT

Hello Romal,

Sorry for the long response time. I was out of the office for quite a while, and this case was originally created by someone else (possibly your colleague). Your comment changed the case status (since you are not the thread creator), which caused it to remain in my queue. That’s why my colleague didn’t take it over during my absence. I’m sorry this happened.

Have you made any progress on this? Please let me know if you are still facing the issue. I will look into it and update you at the earliest.

Kind regards,
Abhijith

RE: Modularisation of a firmware

Romal — Thu, 16 Oct 2025 06:17:58 GMT

Hi,

Thanks for the update.

[quote userid="115767" url="~/f/nordic-q-a/124320/modularisation-of-a-firmware/551638"]I recommend using the latest version of the nRF Connect SDK, as there were major changes introduced after NCS v2.7.0, including the transition to Sysbuild for multi-image builds. There have also been several configuration changes and bug fixes since NCS v2.5.2.[/quote]

We will use the latest NCS version.

[quote userid="115767" url="~/f/nordic-q-a/124320/modularisation-of-a-firmware/551638"]You are correct, this is a limitation of the mcumgr command-line tool, which only works on Linux. The same has been mentioned in this ticket.[/quote]

Noted. Thanks.

[quote userid="115767" url="~/f/nordic-q-a/124320/modularisation-of-a-firmware/551638"]Could you please let me know what file format you are using? I’m not aware of any specific file extension limitations in the Device Manager app, but could you share a screenshot of the error message or collect the logs so we can check further?[/quote]

We are using .bin file. This BIN file is actually different audio data file combined together and signed using the key (.pem) used to signed application firmware file. We have used imgtool.py to signed the file. We are uploading this file to mcuboot_secondary_1 part located in external flash memory. This file is non-bootable. Application firmware read the audio data from this location. Below is the partition info for your reference and also attached the log from nrf Connect Device manager app.

devzone.nordicsemi.com/.../Log-2025_2D00_10_2D00_16-11_5F00_35_5F00_47.txt

Got your clarification about signing the image and slot configuration. Thanks.

Would you please help us about uploading file issue?

Thanks,

Romal.

RE: Modularisation of a firmware

Menon — Wed, 15 Oct 2025 20:34:15 GMT

Hello,

I recommend using the latest version of the nRF Connect SDK, as there were major changes introduced after NCS v2.7.0, including the transition to Sysbuild for multi-image builds. There have also been several configuration changes and bug fixes since NCS v2.5.2.

[quote user="Romal"] We like to test this using BLE. Looks like mcumgr BLE transport support is not available for windows?[/quote]

You are correct, this is a limitation of the mcumgr command-line tool, which only works on Linux. The same has been mentioned in this ticket.

[quote user="Romal"]Can we test the same using nRF Connect Device manager phone application? If yes, can you please explain how can we do that? we have tired using "file" option but it failes. Giving error "Upload failed: Not supported (8)".[/quote]

Could you please let me know what file format you are using? I’m not aware of any specific file extension limitations in the Device Manager app, but could you share a screenshot of the error message or collect the logs so we can check further?

[quote user="Romal"]We need to signed the file with imgtool before uploading it. Without this mcumgr not uploading file. Is this neccessary to sign the file? Can we skip this?[/quote]

Regarding the signing requirement, this is necessary for the bootloader to validate and ensure the integrity of the image. If the image is unsigned, the upload may be refused.
When you build your application in nRF Connect SDK, the build system automatically signs the image with a default development key. For production, you must use your own signing key.

[quote user="Romal"]We need to create two slot, mcuboot_primary_1 and mcuboot_secondary_1 for image-1. Can we not use only single slot?[/quote]

If you’re asking whether single-slot DFU over BLE is supported, unfortunately, it is not supported at this time. The feature is planned for a future release, but I don’t have a specific timeline to share.

Kind Regards,

Abhijith

RE: Modularisation of a firmware

Romal — Tue, 14 Oct 2025 06:35:07 GMT

Hello Abhijith,

As you mentioned, we have used mcumgr to transfer the audio data to external flash. We have configured mcumgr transport to use serial and BLE both.

In our device we have used external flash as image-1 (define two slots mcuboot_primary_1 and mcuboot_secondary_1). We are uploading the audio file to slot 1 (n = 1).

We have successfully uploaded and tested the file using mcumgr serial transport with our windows system. We like to test this using BLE. Looks like mcumgr BLE transport support is not available for windows?

Below are the few questions regarding this,

Can we test the same using nRF Connect Device manager phone application? If yes, can you please explain how can we do that? we have tired using "file" option but it failes. Giving error "Upload failed: Not supported (8)".
We need to signed the file with imgtool before uploading it. Without this mcumgr not uploading file. Is this neccessary to sign the file? Can we skip this?
We need to create two slot, mcuboot_primary_1 and mcuboot_secondary_1 for image-1. Can we not use only single slot?

We are using nRF Connect SDK version 2.5.2 and our device is using BLE coded phy.

Thanks,
Romal

RE: Modularisation of a firmware

Menon — Tue, 30 Sep 2025 17:03:23 GMT

Hello,

Lets break down the requirement into three parts: transfer, write, and read.

For the transfer part there are several options: a custom protocol, mcumgr/SMP, using the image command by configuring another region to behave like an image slot and then writing a .bin into it, or using the filesystem command (fs), since mcumgr supports filesystem operations and a filesystem partition can be set up for this purpose (with the requirement that it be bound to a filesystem for both read and write).

For the write part, multiple options are possible: NVS for small, frequently updated data, direct use of the flash driver for raw data blobs, or other filesystems like LittleFS for larger data that benefit from safe file handling.

The read part is entirely on the application side, the way the application reads the data will then depend entirely on how it is stored.

This way, firmware updates don’t touch the audio data, and you can also update the audio later without having to reflash the whole device.

Kind Regards,

Abhijith

RE: Modularisation of a firmware

Paskin — Wed, 24 Sep 2025 07:33:26 GMT

Hi Abhijith,

Thanks again for following on this with me.

Could you emphasise a bit on "sending a separate file to the dedicated audio partition" process?

What is the expected format of this file, and how the OTA framework shall be "told" that incoming binary is not a firmware, but shall be loaded into the "audio" partition? Shall I code this, or it can be achieved with some metadata?

Could you refer me to some example?

Thanks,
Dmitry

RE: Modularisation of a firmware

Menon — Tue, 23 Sep 2025 12:31:44 GMT

Hello,

No, keep the partitions separate with pm_static.yml, then send a firmware image when you want to update the code, and send just the audio data when you want to change phrases,no need to reflash everything together. For firmware OTA, you upload the signed application image (app_update.bin) via MCUboot as usual. For your audio data, you send a separate file to the dedicated audio partition.

Kind Regards,

Abhijith

RE: Modularisation of a firmware

Paskin — Sun, 21 Sep 2025 11:01:31 GMT

HI Abhijith,

Thanks for your reply.

Does "updating separately" mean pushing the HEX file containing only the required partition instead of default merged.hex?

Best regards,
Dmitry

RE: Modularisation of a firmware

Menon — Fri, 12 Sep 2025 09:48:52 GMT

Hello,

I think you can use the partition manager to define a proper partition for storing the audio data. In the pm_static.yml, define an additional partition for audio (similar to an NVM partition).

This keeps it separate from the firmware, allowing you to update either one independently. Please refer to the partition manager documentation for more details.

Kind regards,
Abhijith