Zigbee FOTA update won't apply

Hi,

I am currently developing a custom Zigbee end device with support for FOTA updates. My FOTA seems to work (all data gets transferred correctly) but the update won't apply. The device just restarts and still has the same MCU boot version. For testing FOTA, I am using the Zigbee Light Switch example. Please check my Wireshark capture and see if anything is wrong with the transfer (header, subelement header...). The secur key of the coordinator I am using is: "9d557f5dac6d327963c2d984083b9e7d". 
I am using NRF connect in VS Code with SDK version v2.5.2.

Thanks in advance!

Best Regards,

Pieter-Jan Buntinx

OTA_transfer_capture.pcapng

  • 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

  • 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

  • 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

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

Related