Modularisation of a firmware

[Paskin]

Hello

Our 52840-based device has a functionality of playing one of 10 pre-recorded phrases via I2S interface. We'd like to be able to update the wording or load a different language via OTA, separately from the firmware, and the other way around - update firmware without touching the audio data. The device has external flash and MCUBoot. 

Please advise, 

Thanks, 
Dmitry

[Menon]

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

[Paskin]

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

[Menon]

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

[Paskin]

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

[Menon]

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