In SDK version 2.9.0, the OTA process fails to retrieve the correct firmware version

[SunHuang]

After completing the OTA update, I executed the "otasoftwareupdaterequestor read-event version-applied" command but was unable to read back the version.

I then tried the "basicinformation read software-version" command and found that the version had not been updated, although the firmware functionality had indeed been updated.

The correct firmware version can also be seen from the "provider". What could be causing this issue?

1524.ota.zip

[Amanda Hsieh]

Hi, 

Both issues are related. The event is generated only if after a reboot the current software version is the same as the version encoded in the header of the OTA image that was to be applied. It seems as if you only updated the version in the OTA image header but not in the firmware itself.

Do you use the VERSION file for the firmware versioning or the CONFIG_CHIP_SOFTWARE_VERSION Kconfig option?

[SunHuang]

Hi,

I "only" use VERSION to control the firmware version. When the device boots up, it prints out CHIP_DEVICE_CONFIG_DEVICE_SOFTWARE_VERSION to verify whether the firmware version has been correctly updated. However, CHIP_DEVICE_CONFIG_DEVICE_SOFTWARE_VERSION has already been updated. So, how should I resolve this issue?

[Amanda Hsieh]

SunHuang said:

I "only" use VERSION to control the firmware version. When the device boots up, it prints out CHIP_DEVICE_CONFIG_DEVICE_SOFTWARE_VERSION to verify whether the firmware version has been correctly updated. However, CHIP_DEVICE_CONFIG_DEVICE_SOFTWARE_VERSION has already been updated.

It seems the DFU works fine as expected. In such a case, the basic information cluster should return the "wrong" version if you don't update. Could you program the new firmware to see if you can get the correct version?  Also, could you share your VERSION file, in the old and new firmware versions?

[SunHuang]

If I directly flash the firmware, I can get the correct version. In the end, I found that "occasionally" the version can still be read through read-event version-applied. This instability could cause issues for us when obtaining Matter certification.

Amanda Hsieh said:

Could you program the new firmware to see if you can get the correct version?

ver.zip

[Amanda Hsieh]

Getting the version-applied event can indeed be investigated as there can be multiple reasons why it's not delivered, but I would like to first understand how is this possible that

• after DFU "basicinformation read software-version" shows the old version, but you see a new functionality
• if you program the new firmware directly "basicinformation read software-version" shows the new version

Are you sure the behavior is like this? As if you didn't modify the code for accessing the software version, the software version is just a constant in the firmware so the same value should be returned no matter if the new firmware was flashed directly or installed as an upgrade.

Also, the initial logs show that chip-tool received version SoftwareVersion: 34144256 (0x2090000, that is 2.9.0.0) yet the VERSION files they provided contain 0.0.1.0 and 1.0.1.0 versions, respectively. Does it mean that originally you didn't update the VERSION file?

[SunHuang]

Hi,

Please ignore oftwareVersion: 34144256, as this is the experimental result from my test on the development version using a sample code(matter lock). Since you requested the VERSION file currently in use, I have provided my project's VERSION file.

In any case, neither of them can retrieve the correct version using "otasoftwareupdaterequestor read-event version-applied". However, my own project is able to read the correct version using "basicinformation read software-version" after executing the OTA update.

So please focus on the issue where "otasoftwareupdaterequestor read-event version-applied" fails to retrieve the version.

[Amanda Hsieh]

Which version of NCS and chip tool are you using?

Do you use the corresponding version of NCS and chip tool?