• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 57 subscribers
  • Views 379 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652RB: Zigged OTA aborted by device shortly after starting update

A V
Prodigy 180 points
Part Number: CC2652RB
Other Parts Discussed in Thread: , UNIFLASH

Hello. I have been trying to get OTA to work for some time now on my temperature sensor project. My implementation uses SDK version 6.20.00.29 and work really well otherwise. The problem I have is that, when trying to update using Zigbee2Mqtt, I get an error saying that OTA was aborted by device. Logs below:

Zigbee2MQTT:debug 2024-03-19 11:20:13: Received Zigbee message from 'Batch2 Sen5', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"fileVersion":1,"imageType":9810,"manufacturerCode":48830}' from endpoint 8 with groupID 0
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Request offsets: fileOffset=0 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Payload offsets: start=0 end=32 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Update at 0%, remaining Infinity seconds
Zigbee2MQTT:info  2024-03-19 11:20:14: Update of 'Batch2 Sen5' at 0.00%
Zigbee2MQTT:info  2024-03-19 11:20:14: MQTT publish: topic 'zigbee2mqtt/Batch2 Sen5', payload '{"battery":0,"humidity_8":0,"linkquality":87,"temperature_8":-40,"temperature_9":-40,"update":{"installed_version":1,"latest_version":2,"progress":0,"state":"updating"},"update_available":null,"voltage":4100}'
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Request offsets: fileOffset=32 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Payload offsets: start=32 end=64 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Request offsets: fileOffset=64 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Payload offsets: start=64 end=96 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Request offsets: fileOffset=96 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:14: OTA: Payload offsets: start=96 end=128 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Request offsets: fileOffset=128 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Payload offsets: start=128 end=160 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Request offsets: fileOffset=160 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Payload offsets: start=160 end=192 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Request offsets: fileOffset=192 pageOffset=0 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Payload offsets: start=192 end=224 dataSize=32
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Got upgrade end request for '0x00124b0031e5d997' (AFTSHT35X2): {"status":149,"manufacturerCode":48830,"imageType":9810,"fileVersion":2}
Zigbee2MQTT:debug 2024-03-19 11:20:20: OTA: Update failed with reason: 'aborted by device'
Zigbee2MQTT:debug 2024-03-19 11:20:20: Update of 'Batch2 Sen5' failed (Error: OTA: Update failed with reason: 'aborted by device')

I was unable to validate OTA using OTAServer utilities and LP-CC2652RB boards because I could not get them to pair. Coordinator appears in the app when I connect it via serial, but I cannot get them to pair and am unable to see the joining devices with the provided examples. Anyways, I could still validate that TI's implementation of OTA is working by using the zr_sw_ota_client_LP_CC2652RB_tirtos_ticlang example and pairing it to my coordinator using Home Assistant. The update worked and the full image was downloaded.

I then took the ota directory of that project, added it to mine and rebuilt the project to test it. Now, unlike the sample project, it only seems to download a couple to packets then I get a message saying that the update was aborted. I have not modified anything inside the ota files and only added the ota_process_loop function to my main loop.

When debugging through the code, I got no hit inside otaClient_UpgradeComplete, but I can see that the app periodically asks for updates and receives a couple of frames as per the logs. Any idea what might be causing this or how can I better debug it?

Additional question: My device is a two-endpoint temperature sensor with two temperature clusters. Should I implement OTA cluster on both of them? It is currently only implemented on the main endpoint. I can still check for updates and initiate an update, but cannot finish it. Everything else works fine with respect to attribute reporting, commissioning and device stability.

My device is a battery-powered end device based on zed_temperature_sensor with the added ota cluster and second endpoint. Power source is set as battery and power cluster is configured and working correctly. OTA doesn't work regardless of the board being powered by battery of through the debugger. Are there special settings for battery powered OTA devices?

  • 0
    TI__Guru**** 205707 points

    Hello A V,

    Please make sure you have followed all steps from the Adding Client Functionality to an Application section of the Z-Stack User's Guide for your zr_temperaturesensor.  You need to confirm that this works with zc_ota_server and that zr_sw operates successfully with Zigbee2MQTT.  Only then should you proceed with Zigbee2MQTT and zr_temperaturesensor.  You will need to capture sniffer logs and determine the call to zclOTA_SendUpgradeEndReq/otaClient_UpgradeComplete which results in the ZOtaAbort status.  You can work backwards from there to discover the root cause within your application

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 180 points

    Hello, Ryan

    Sorry for my belated response, I hope you still follow this topic. I have delved deeper into the issue and setup the sniffing tools as directed in the guide. I can now connect the coordinator to the ota server app and start sniffing with Ubiqua. However, I cannot seem to be able to decrypt any Zigbee messages using the key provided in the resources you attached. 

    I setup the 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39 key within Ubiqua, as Application or Trust Center Link Key, but all messages bear an 'Unable to decrypt' packet information. I followed your colleague's suggestion in starting the sniffer before forming the network, but the results are the same. I've tried changing the type of the key, but to no avail. I've setup the correct channel as configured in sys cfg and can see the traffic, but cannot see any info. I've also tried closing and opening all the apps as well as reflashing the boards.

    Would appreciate if you have further suggestions on how to overcome this.

  • 0 in reply to A V
    TI__Guru**** 205707 points

    YK's suggestions are correct.  You've also tried the recommended changes based on your description, although the image you shared betrays the notion of a device joining.  Please revert your code to default TI examples from the SDK and send a sniffer log which includes a fresh ZC device forming the network and allowing factory reset ZR/ZEDs to join.  You should at least see Beacon Requests and Association Requests/Responses as these are unencrypted MAC packets.  You can also try to put in the TCLK manually through the Packet View, but this is a moot point for devices which have completed the TCLK update process or packets using the NWK key (randomly selected for the network by the ZC) after having joined.  I've attached an example Ubiqua capture for your reference.  3.0_ZC_ZR_ZED.cubx

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 180 points

    Hello, Ryan. Thanks to you and YK for your suggestions; I got this working, finally.

    If anyone else is having issues with this, is how I could reliably get the sniffer to work: full chip erase of the coordinator and ZED boards (I use UniFlash), new flash with the firmware, then closing the OtaServer and Ubiqua apps and restarting them. Connecting the sniffer board and starting Ubiqua with the trusted key, and only then can you build the network and pair the ZED.

    Anyways, I used zc_ota_server_LP_CC2652RB_tirtos_ticlang as the server app and zed_sw_ota_client_LP_CC2652RB_tirtos_ticlang as the ZED device. Unfortunately, I could not use the fully stock version of the zed_sw_ota_client_LP_CC2652RB_tirtos_ticlang fw and had to remap CONFIG_BTN_LEFT to GPIO 22 in order to match my custom sensor board; I only have 2 launchpads available. Even though the sniffing works now, OTA still doesn't. 

    I can see through the logs the network formation and device discovery, but shortly after ota starts, it stops. Will attach my log files for further reference. As far as I see, message 181 is an 'Upgrade End Request' issued by ZED. This is weird, as the behaviour seems to be identical to my custom implementation of the temperature sensor, with the exception that this is an example provided by TI.

    Could this be a hardware issue with the flash? I used the same flash as the LPCC2652RB. 

    For some reason, e2e does not allow me to upload this log file, so here's wetranser: https://we.tl/t-jPYcKx0h31 

  • +1 in reply to A V
    TI__Guru**** 205707 points

    Thanks for the sniffer log, I can see now that the ZED is reporting a status code of Abort inside of the Upgrade End Request after ignoring the latest Image Block Response from the ZC.  I had not realized before that you were using a custom board and I agree that the external flash memory is highly suspect at this point.  The predominant issue is that the Factory Image has not been programmed onto a non-TI board, as explained in the Building and Downloading Target Applications section. 

                            // Read the factory new metadata page
                        readFlash(EFL_ADDR_META_FACT_IMG, (uint8_t *)&oad_imgHdrFactoryNew, EFL_METADATA_LEN);

                        //is a valid header
                        if(memcmp(&oad_imgHdrFactoryNew.fixedHdr.imgID, oad_externalFLashID, sizeof(oad_externalFLashID)) != 0)
                        {
                            flash_close();
                            //This release does not support not having the Factory New image
                            return ZCL_STATUS_ABORT;
                        }

    You can try to program the factory image as described, remove the code which checks for it, or chip swap external flash memory components with one from a TI LaunchPad.  If these do not resolve your issue, I recommend that you debug zcl_ota.c for instances where ZCL_STATUS_ABORT is returned.  

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 180 points

    Hello, Ryan. You are right, thank you! This solved my issue and am now able to reliably perform updates on my custom board.

    Just one more thing: I have a multi-threaded application with a separate thread dealing with sensor management and it seems that after the boot loader restarts the application, the program does not start from the beginning, thus I have issues in discerning when the device has been commissioned. I have a boolean flag that I use to denote that the device has been commissioned so as to not needlessly perform ADC measurements and drain the battery much too soon.

    Currently, I use _ProcessCommissioningStatus to check the following events for a successful commissioning: BDB_COMMISSIONING_NWK_STEERING, BDB_COMMISSIONING_FINDING_BINDING,  BDB_COMMISSIONING_SUCCESS. It seems that these events do not get triggered anymore and cannot confirm that I am successfully commissioned. 

    If I remove the check for the Commissioning flag, the ADC correctly sends the sensor data to the stack and the sensor functions as expected. However, were I to not use this flag, it would cause high power consumption in the cases in which the sensor has not been commissioned or the network is down.

    Are there other events I could capture to make sure I am safely commissioned after OTA?

  • 0 in reply to A V
    TI__Guru**** 205707 points

    I'm glad to hear that the previous issue is resolved.  Your next observation is likely due to your commissioning flag being based on a new join, which does not consider rejoins as would be the case with an OTA upgrade.  You can instead monitor the zstackmsg_CmdIDs_DEV_STATE_CHANGE_IND case for zstack_DevState_DEV_END_DEVICE/zstack_DevState_DEV_ROUTER.  There are other locations you can also check such as Zstackapi_sysNwkInfoReadReq, NIB nwkState, and bdbAttributes bdbNodeIsOnANetwork which can be checked at any time.

    Regards,
    Ryan