Retrieve MCUBoot version from main application

[Udi Vahaba]

Hi,

I'm trying to retrieve the MCUBoot version inside my application (from the VERSION file).

In the Zephyr documentation (docs.zephyrproject.org/.../index.html), I found that I can access app_version.h (located in /app/build/app/zephyr/include/generated/app_version.h).

A similar file exists in the MCUBoot build folder (/app/build/mcuboot/zephyr/include/generated/app_version.h).

I'm facing two problems:
1) I can't find a way to include the MCUBoot app_version.h file in my code.
2) Assuming I can include it, it uses the same macro names as the application. In my code, I need to use both the application version and the MCUBoot version. How can I modify the macro names generated for MCUBoot to avoid conflicts?

thanks

[Sigurd Hellesvik]

Hi,

Do you have dual bootloaders so you can upgrade MCUboot?

Which version of the SDK do you use?

Regards,
Sigurd Hellesvik

[Udi Vahaba]

Hi,

I have dual bootloader (NSIB + MCUBoot).

using sdk 2.7.0 (will update later to latest)

[Udi Vahaba]

Yes, I want to have the current version of mcuboot.

I'm using that to check if i need to upgrade the mcuboot firmware

[Sigurd Hellesvik]

NSIB uses FW Info to keep track of MCUboot version.

You can use the FW info API to read out the FW Info version from MCUboot. This should be enough to know if you need to upgrade MCUboot.
Try this and let me know how it goes.

[Udi Vahaba]

Hi Sigard,

Thank you for your response. I’ve been trying to use the FW Info API as suggested, but I’m still struggling with some aspects. I need to gather the following data before proceeding with the DFU for MCUBoot:

1. Determine which slot is active (s0/s1):
   The issue here is that the version alone isn’t enough. For example, the second slot might have a newer version, but if it’s invalid, it doesn’t count, and only the other slot would be relevant. In this case, I need to reliably determine the active slot.

2. Retrieve the firmware version:
   For this, I have an idea: I plan to read the TLV using the fw_info struct to extract the uint32_t version variable. Is this a good way to retrieve the version at runtime? Alternatively, should I use retained memory to get this information, assuming MCUBoot has the ability to write to that area?

Could you please confirm if this is the correct approach, or suggest any better alternatives?

Thanks for your help!

[Sigurd Hellesvik]

We do something similar in TF-M. See here. You can check both the version and if the slot is valid using FW Info.

[Udi Vahaba]

Thanks,

I tried working with this, but the version (from byte 20) is always 0.

I tested it with three different versions (changing the VERSION file from 2.1.0 to 2.2.0 and 2.3.0), but none of these versions appeared in the hex file.

Next, I checked the zip file generated during the build process, and the manifest file showed the following values: "version_MCUBOOT": "0.0.0+0" for both s0 and s1.

Does this mean I cannot retrieve the version of MCUBoot using this method?

[Sigurd Hellesvik]

Try to change CONFIG_FW_INFO_FIRMWARE_VERSION. Can you read that?

[Udi Vahaba]

I changed the CONFIG_FW_INFO_FIRMWARE_VERSION. still zeros from byte 20.

same goes for the manifest inside the zip.

[Sigurd Hellesvik]

Hold up, why do you talk about byte 20?

Did you not try the FW Info library?

[Udi Vahaba]

because i want to know what is the version of mcuboot. not the version i declare it is.
the CONFIG_FW_INFO_FIRMWARE_VERSION value can be set to be 300 if i want, but it wont let me know that a real new MCUBoot version is out.

as i said, in my code i perform DFU to upgrade the mcuboot. but to do that i need to know that the version was changed.

The usage of FW Info was an attempt to grab this data, but as long as im digging into the mcuboot versioning i see that the VERSION file info is not embedded into the binary file! 

[Sigurd Hellesvik]

Udi Vahaba said:

because i want to know what is the version of mcuboot.

But why?

If you build your project, you are free to set both MCUboot version and FW_INFO version right?

In this case you can make sure FW_INFO mathces MCUboot version, and the product should work the same right?

From what I know, we decided to use FW_INFO instead of the Zephyr version of MCUboot when adding the feature for updatable bootloaders and therefore we have not implemented any way of reading MCUboot version. This is why I recommend FW_INFO.

I am maybe a bit difficult here, but knowing the use-case to why you need this version will help me best help you in finding the best solution