Zigbee FOTA update won't apply

RE: Zigbee FOTA update won't apply

Menon — Tue, 06 Aug 2024 12:42:19 GMT

Hello,

Always happy to help. I am closing this ticket as your issue has been resolved.

Please don't hesitate to create a new ticket if you come across a different issue in the future.

Kind Regards,

Abhijith

RE: Zigbee FOTA update won't apply

pjbuntinx — Mon, 05 Aug 2024 13:54:43 GMT

Thank you for the help :)

RE: Zigbee FOTA update won't apply

Menon — Mon, 05 Aug 2024 12:41:53 GMT

Hello,

Glad to hear that your issue has been resolved.

Kind Regards,

Abhijith

RE: Zigbee FOTA update won't apply

pjbuntinx — Mon, 05 Aug 2024 12:03:21 GMT

I can now successfully do OTA updates. The problem was not with the signing of the image but with a wrong image size.

RE: Zigbee FOTA update won't apply

Menon — Tue, 23 Jul 2024 09:53:59 GMT

Hello,

[quote user="pjbuntinx"]I have added: CONFIG_MCUBOOT_SIGNATURE_KEY_FILE=" C:/ncs/v2.5.2/bootloader/mcuboot/root-rsa-2048.pem"[/quote]

Try using the CONFIG_BOOT_SIGNATURE_KEY_FILE configuration instead of the one you mentioned. Note that this should be included in the MCUboot configuration, not in the application configuration (prj.conf). Take a look at this GitHub repository; there are some samples for your reference, though please note that these are not official samples. See this section as well.

Kind Regards,

Abhijith

RE: Zigbee FOTA update won't apply

pjbuntinx — Fri, 19 Jul 2024 10:12:13 GMT

Maybe something dumb I am doing wrong but I cannot get it building when adding a key_file.

I have added: CONFIG_MCUBOOT_SIGNATURE_KEY_FILE=" C:/ncs/v2.5.2/bootloader/mcuboot/root-rsa-2048.pem"
To my prj.conf file, I have also tried using the commands of the page you mentioned. I have also tried generating a key myself using this guide. But I always get the following error:

C:/{BUILD_DIR}/build_DK/zephyr/misc/generated/extra_kconfig_options.conf:3: warning: malformed string literal in assignment to MCUBOOT_SIGNATURE_KEY_FILE (defined at modules/Kconfig.mcuboot:50). Assignment ignored.

Below you can find the contents of the priv key I generated myself:

RE: Zigbee FOTA update won't apply

Menon — Tue, 16 Jul 2024 13:14:20 GMT

Hello,

After reviewing the logs, I suspect the issue might be related to image signing. Have you followed all the steps mentioned on this page? Ensure that the firmware image being sent over OTA is correctly signed and validated before the update process.

Kind regards,

Abhijith

RE: Zigbee FOTA update won't apply

pjbuntinx — Mon, 15 Jul 2024 15:04:20 GMT

Hi Abhijith,

I have managed to get the logs. Besides not following the tutorial you mentioned, I could not get them because I was using RTT. Now with the DK board and the serial console, I get the following output after a "successful" OTA:

*** Booting nRF Connect SDK v2.5.2 ***
I: Starting bootloader
I: Primary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0x2
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting nRF Connect SDK v2.5.2 ***
I: Starting bootloader
I: Primary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0x2
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting nRF Connect SDK v2.5.2 ***
I: Starting bootloader
I: Primary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0x2
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
D: erasing trailer; fa_id=2
D: initializing status; fa_id=2
D: writing swap_info; fa_id=2 off=0x74fd8 (0x80fd8), swap_type=0x2 image_num=0x0
D: writing swap_size; fa_id=2 off=0x74fd0 (0x80fd0)
D: writing magic; fa_id=2 off=0x74ff0 (0x80ff0)
D: erasing trailer; fa_id=5
D: writing copy_done; fa_id=2 off=0x74fe0 (0x80fe0)
I: Bootloader chainload address offset: 0xc000
�*** Booting nRF Connect SDK v2.5.2 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0xc000
�*** Booting nRF Connect SDK v2.5.2 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0xc000
�: Jumping to the first image slot

After this, the device seems bricked and I am unable to make it work again without reflashing.

Kind regards,

Pieter-Jan

RE: Zigbee FOTA update won't apply

Menon — Thu, 11 Jul 2024 12:29:52 GMT

Hello,

Edvin is on vacation, so I will look into your issue in the meantime.

Are you enabling the log by including those configurations inside the prj.config file? If so, that won't work because to configure the mcuboot, you need to include these configurations inside the child_image (child_image\mcuboot.conf) folder. Please refer to the tutorial pointed out by my colleague in his last response.

Kind regards,

Abhijith

RE: Zigbee FOTA update won't apply

pjbuntinx — Wed, 10 Jul 2024 08:53:03 GMT

Hi Edvin,

`CONFIG_MCUBOOT_LOG_LEVEL_INF` does not seem to exist (anymore). I have tried enabling `CONFIG_MCUBOOT_UTIL_LOG_LEVEL_INF` but I don't seem to get the correct output on boot. I have attached my prj.conf file below.

devzone.nordicsemi.com/.../82587.prj.conf

RE: Zigbee FOTA update won't apply

Edvin — Wed, 03 Jul 2024 12:46:35 GMT

Please see step 2.3 in this course. It show you how to enable logging in the bootloader. See if the log from the bootloader says anything useful after the image is transferred.

Best regards,

Edvin

RE: Zigbee FOTA update won't apply

pjbuntinx — Fri, 28 Jun 2024 13:46:12 GMT

I have tried enabling some more logging. But there was no additional output in the console. I have additionally enabled the following items in Kconfig:

CONFIG_IMG_MANAGER_LOG_LEVEL_DBG=y

CONFIG_DFU_TARGET_LOG_LEVEL_DBG=y

CONFIG_ZIGBEE_FOTA_PROGRESS_EVT=y

What items should I enable to show the bootloader logs?

RE: Zigbee FOTA update won't apply

pjbuntinx — Thu, 27 Jun 2024 22:56:25 GMT

Hi Edvin,

No, I don't have any. I will check tomorrow in the kconfig if I can enable some more logging for this. Now that I think about it more, that is something I should have tried already.

Are both the applications (old and new) based on the same SDK version? And are both applications built with the bootloader?

Yes, both applications are from the same SDK version. They are the same applications but just with a different CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION. There is to my knowledge no bootloader included in the images. According to what I have read on this forum, bootloader upgrading is not supported over Zigbee FOTA in the SDK.

Does the new application work if you flash it together with the bootloader, like you did with the first application?

What do you mean by flashing it together with the bootloader? The second message I posted over here is the console log you get after the NRF device sends the Zigbee OTA end request and finishes the OTA. So the Wireshark capture and the console logs belong together and are not separate from each other. These two were not from the same transfer but they show the same result in the console log.

How did you upload the new application?

To upload an initial firmware that is FOTA upgradeable I am using VSCode together with the NRF Connect extension. I upload the firmware to a custom board with an NRF52840 chip using a NRF5340DK as the Jlink connection. I also have access to NRF52840DKs and NRF52840 USB dongles. But this does not make a difference.

What did you use as the FOTA server?

I am using an ESP32-C6 as a Zigbee coordinator and I have also tried using Zigbee2MQTT to do the OTA with the same result. But it should not matter what device I am using to do the OTA with. When looking at the Wireshark captures, everything seems in order compared to the Zigbee Cluster specifications.

And what file/image did you put into it?

After building the project in VSCode, NRF connect generates a Zigbee OTA file in the format "{manufacturer id}{image_type}{mcu_boot_img_tool_version}.zigbee". That is the file I am transferring. For the ESP32 coordinator, I am removing the first 56 bytes (the Zigbee header) since this device generates its own header and otherwise two headers would be sent. There seems to be no difference in the header generated by the ESP chip or the header in the image build by the NRF SDK.

Best Regards,

Pieter-Jan Buntinx

RE: Zigbee FOTA update won't apply

Edvin — Thu, 27 Jun 2024 21:29:45 GMT

Hello,

Do you have any logs from the bootloader? It may very well be that the transfer is successful, but that the bootloader for some reason rejects the image.

A couple of starting questions:

Are both the applications (old and new) based on the same SDK version? And are both applications built with the bootloader?

Does the new application work if you flash it together with the bootloader, like you did with the first application?

How did you upload the new application? What did you use as the FOTA server? And what file/image did you put into it?

Best regards,

Edvin

RE: Zigbee FOTA update won't apply

pjbuntinx — Thu, 27 Jun 2024 15:14:21 GMT

Here is the console log of the NRF device. This is not the log of light switch example but I get the same result with that example.

[01:26:32.658,203] <inf> zigbee_fota: Full image downloaded.
[01:26:32.658,508] <inf> zigbee_fota: New OTA image downloaded.
[01:26:32.693,115] <inf> zigbee_fota: Mark OTA image as downloaded.
[01:26:33.070,343] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[01:26:34.070,526] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[01:26:35.070,709] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[01:26:36.070,892] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[01:26:37.071,075] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[00:00:00.000,518] <inf> ieee802154_nrf5: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.5.2 ***
[00:00:00.010,101] <inf> app: Starting ventilation unit...
[00:00:00.010,284] <err> app: Couldn't confirm image: -5
[00:00:00.010,559] <inf> app: 


err install_code: 0



[00:00:00.011,840] <inf> app: Zigbee application template started
[00:00:00.011,871] <inf> modbus_serial: RTU timeout 2005 us
[00:00:00.011,932] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[00:00:00.013,977] <inf> zigbee_app_utils: Production configuration is not present or invalid (status: -1)
[00:00:00.014,617] <inf> zigbee_app_utils: Zigbee stack initialized
[00:00:00.055,572] <inf> zigbee_app_utils: Unimplemented signal (signal: 54, status: 0)
[00:00:00.059,295] <inf> zigbee_app_utils: Joined network successfully on reboot signal (Extended PAN ID: 6055f90000f69bb0, PAN ID: 0xc341)
[00:00:01.012,115] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1

[00:00:02.012,298] <inf> app: Current address: f4ce366a8ab1d5a9, fw version: 0.0.1