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)

[Sigurd Hellesvik]

You say you would want to include mcuboot's header in your code. But with this, you would only have the version the code was built with and not the updated version of MCUboot. Is this what you want?

Or would you rather want to check MCUboot version in realtime?

What is your use-case for knowing the version?

[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?