Multi image project as Zephyr module

[a_ku]

Hello,

I've been working with nRF9160 for a while now and wanted to let you know, I love this little piece of hardware. The possibilities, the small form factor, the power consumption - everything seems to be really great! 

About the issue. I've created a base project (lets call it "core" later on) which includes minimum functionality required for any upcoming projects/devices. Core utilizes MCUboot and TF-M so it is a multi-image build. Now I want to add core as a nested project for a specific sensor device. Meaning I include the core project in my new device project (its like a module or subsys or something else), write some sensor drivers, change some settings and FW is done. 

What are my options here? I thought maybe I could utilize Zephyr modules and use the core project like a module to the necessary projects but that introduced a lot of build errors. Also it did not directly include core prj.conf or core mcuboot.conf which are necessary. 

The easiest way to get this working is just by branching off core project for each device project but that does not seem like a good way to do it. Maybe there are some more modular possibilities to achieve the result? 

Maybe there is some guide to achieve this? 

I believe the Zephyr module would work great if the core wouldn't be a multi-image build project.

Regards, 
Adrian

[AHaug]

Hi Adrian,

First of I recommend you to have a look at the fundamentals, intermediate and the cellular course on our academy pages, which will go through some more of the basics of maintaining a code "core" as you call it and to use this as a fundament to branch out to other modular projects. https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf91/index.html is also a great resource to have at hand.

Most of this may be redundant information as I don't know your knowledge level, but nonetheless the pages are great to know of.

So to one (maybe all) of your questions:

The easiest way to get this working is just by branching off core project for each device project but that does not seem like a good way to do it. Maybe there are some more modular possibilities to achieve the result? 

The way I understand how you describe your "core" is similar to the approach within NCS where the samples are tailored to show various concepts and show them relatively simple. In your case, you could for instance have "Adrians hello world featuring mcuboot with dual bank dfu and TFM" as your basic application and then make a copy of this "template" and add the features you need for your various applications. It is very flexible and how you maintain it can be very up to you. Do note that it might be hard to maintain your core over multiple releases of the SDK, so I would recommend that you have one "core" for every release you intend to work with and/or to migrate the core according to the migration guides on our documentation pages.

Let me know if I've answered some or all of your questions

Kind regards,
andreas 

[a_ku]

Hi Andreas,

Sorry for the late response. The site was not working for me today up until now.

AHaug said:

First of I recommend you to have a look at the fundamentals, intermediate and the cellular course

Thanks for sharing these. I've been working with nRF9160 for a while now. At the beginning of getting to know nRF9160 I went thru all these courses and at some point of development I returned to some specific topics for a real life case!

The suggested approach seems to be the same idea which I did not quite like - to have a base project and just copy/paste it for each device, which could work just fine to be honest. Ultimately the idea is to build some sort of SDK (not really sure I can call it like that) that relies on nRF SDK with this 'core' app embedded in it. The end user could create his project with 'core' functionality already added, write the .overlay, .conf and other necessary configuration files and his project is up and running. It just does not seem a good solution that end user need to copy/paste base project and then add the necessary sensor drivers or whatever he needs to 'src', 'inc' folders. I hope I explained myself well enough for you to understand. 

Okay but what are the zephyr modules used for then? Are they just like libraries of simple (single image) projects? Based on Zephyr modules description they seem like the ideal solution to my problem but i guess not in the case of multi-image build.

Maybe any other ideas how could I achieve the above mentioned goal?

Best regards,

Adrian

[a_ku]

Hi Andreas,

Could the Sysbuild be able to do what I am trying to achieve here?

Based on the documentation: "Sysbuild works by configuring and building at least a Zephyr application and, optionally, as many additional projects as you want. The additional projects can be either Zephyr applications or other types of builds you want to run", so I guess I will give it a try 

EDIT: correct me if I'm wrong, zephyr modules and sysbuild applications wont work because the TFM and MCUboot inclusion need to be exposed at the top project, right?

[AHaug]

Hi,

a_ku said:

Thanks for sharing these. I've been working with nRF9160 for a while now. At the beginning of getting to know nRF9160 I went thru all these courses and at some point of development I returned to some specific topics for a real life case!

Glad to hear that!

a_ku said:

The suggested approach seems to be the same idea which I did not quite like - to have a base project and just copy/paste it for each device, which could work just fine to be honest. Ultimately the idea is to build some sort of SDK (not really sure I can call it like that) that relies on nRF SDK with this 'core' app embedded in it. The end user could create his project with 'core' functionality already added, write the .overlay, .conf and other necessary configuration files and his project is up and running. It just does not seem a good solution that end user need to copy/paste base project and then add the necessary sensor drivers or whatever he needs to 'src', 'inc' folders. I hope I explained myself well enough for you to understand. 

I've discussed this topic with some of my colleagues and I think I understand what you're aiming for better now. Please verify if I've still not understood what you're after:

Your core application should work as a template for which you and your end users can quickly add modules on top, for instance select a type of DFU and/or BLE features or TFM. In essence yes this is possible with zephyr but it might require a tool tailored for this if you wish to have it as a solution where you ask the users are asked a set of yes/no questions such as "Do you want DFU? A: Y -> single bank serial recovery? A: N ->  dual bank fota? A:Y -> External flash -> A:y and from there you automatically include relevant KConfigs, dts iems, sysbuild configurations and prj.conf.

This is also possible to do with custom project configurations https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_config.html#assigning_kconfig_fragments and CMake options https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/config_and_build/cmake/index.html#providing_cmake_options 

This is to some extent done in a couple of different samples already, and done under the hood for certain configurations, for instance if you set the KConfig for serial recovery it will use that part of the configuration that is relevant from the MCUboot repository within nRF Connect SDK / Zephyr, or within certain samples that has a minimal_prj.conf present you can with a minimal configuration.

a_ku said:

Okay but what are the zephyr modules used for then? Are they just like libraries of simple (single image) projects? Based on Zephyr modules description they seem like the ideal solution to my problem but i guess not in the case of multi-image build.

I think I'm a bit lost here, are you referring to the samples/modules repositoryhttps://github.com/nrfconnect/sdk-zephyr/tree/main/samples/modules? If so, then yes, these are just a set of samples for modules.

a_ku said:

Could the Sysbuild be able to do what I am trying to achieve here?

Based on the documentation: "Sysbuild works by configuring and building at least a Zephyr application and, optionally, as many additional projects as you want. The additional projects can be either Zephyr applications or other types of builds you want to run", so I guess I will give it a try 

Sysbuild will allow you to do this yes, through companion components. This is also present in the build system that preceded sysbuild (child_images), but more limited. This will loop around to my first section in this reply w.r.t doing this with custom project configurations, CMake options as well as you've described: "An application and, optionally, as many additional projects you want..."

Kind regards,
Andreas