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.

Linux/CC2530: How to initiate OTA upgrade to an end device on the network.

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Tool/software: Linux

I am using the Z-stack Linux gateway with Z-stack 3.0.1, and I need some help understanding the process for an end device OTA update, I'm running a test to see if I can upgrade the firmware of a lightbulb.  I found some useful information in the Z-StackLinuxGatewayUserGuide.pdf in section '6.3.3.7 OTA Upgrade'. I followed the instructions and edited the “sample_app_ota.cfg" file on my system in /opt/intwine/ha-gateway/servers/ The original file contents I had were:

/zigbeegateway/misc/ota_sample_images/5678-1234-0000BBBB.zigbee 1 00:12:4B:00:02:3B:29:D9 

I edited that file to read the path to the firmware I want to use in the update and the IEEE address of the device on my network.

/opt/intwine/ha-gateway/misc/ota_sample_images/DimmableLight_JN5168_PWMTCP_60W_A19_2700K_OTA_v12.ota 1 00:15:8D:00:00:CE:0F:3F

The I went into the sample app and pressed "O",  I captured some output from the OTA server:

[15:02:06.666,972] [OTASRVR/LSTN] PKTTYPE:  [ OTASRVR<<SMPLAPP] OtaUpdateEnableReq
[15:02:06.667,210] [OTASRVR/LSTN] PKTBODY:            cmdID = OTA_UPDATE_ENABLE_REQ
[15:02:06.667,283] [OTASRVR/LSTN] PKTBODY:            mode = DOWNLOAD_ENABLE
[15:02:06.668,806] [OTASRVR/LSTN] PKTTYPE:  [ OTASRVR>>SMPLAPP] OtaUpdateEnableCnf
[15:02:06.676,042] [OTASRVR/LSTN] PKTBODY:            cmdID = OTA_UPDATE_ENABLE_CNF
[15:02:06.677,508] [OTASRVR/LSTN] PKTBODY:            status = 0
[15:02:06.680,643] [OTASRVR/LSTN] PKTTYPE: [ OTASRVR<<SMPLAPP] OtaUpdateImageRegisterationReq
[15:02:06.680,991] [OTASRVR/LSTN] PKTBODY:            cmdID = OTA_UPDATE_IMAGE_REGISTERATION_REQ
[15:02:06.681,150] [OTASRVR/LSTN] PKTBODY:            imagePath: <UNKNOWN_TYPE 14>
[15:02:06.681,278] [OTASRVR/LSTN] PKTBODY:            registerUnregister = 1
[15:02:06.681,393] [OTASRVR/LSTN] PKTBODY:            executeTiming = IMMEDIATE
[15:02:06.681,511] [OTASRVR/LSTN] PKTBODY:            updateSupportedDeviceList = 1
[15:02:06.681,626] [OTASRVR/LSTN] PKTBODY:            notification = UNICAST_NOT
[15:02:06.681,808] [OTASRVR/LSTN] PKTTYPE: [ OTASRVR>>SMPLAPP] OtaZigbeeGenericCnf
[15:02:06.681,943] [OTASRVR/LSTN] PKTBODY:            cmdId = ZIGBEE_GENERIC_CNF
[15:02:06.682,153] [OTASRVR/LSTN] PKTBODY:            status = FAILURE

I could use some help interpreting the error message here. What does it mean that the imagePath is an  <UNKNOWN_TYPE 14>? Is the '.ota' update file I'm using not a supported file type for this OTA operation? Or is the sample app simply unable to find my file on the system? Or is it something completely different?

Thanks for your help in this,

-James Mather

  • Hi,

    OTA upgrade images must have the extension ".zigbee", this is the file extension that our OTA file generation tool outputs.

    For info on doing OTA upgrades using the sample app, look for the document "sample_app_ota_readme.txt" in the Docs folder.

  • Thanks for the response, using the wrong file extension could definitely be a problem. To test this out I tried using one of the included Sample Upgrade Image Files, 5678-1234-0000BBBB.zigbee . Even though it is not the correct image file for the device at least I would be able to see the process move along a bit farther. I edited my sample_app_ota.cfg to point to that file:
    /opt/intwine/ha-gateway/misc/ota_sample_images/5678-1234-0000BBBB.zigbee 1 00:15:8D:00:00:CE:0F:3F

    Unfortunately when I attempted to run the OTA from the sample app I got the same error as above:
    imagePath: <UNKNOWN_TYPE 14>.

    Is there anything you would recommend to help debugging this?
  • Hi,

    I found some more information regarding this, let me know if this helps:

    The data from sample_app_ota.cfg is used as an argument to the API command that registers a new image with the OTA server. sample_app_ota.cfg is only used by the sample application when it sends this command, following the user request (pressing ’o’). The sample application does not implement removal of OTA images that have previously been registered. Removing an image from sample_app_ota.cfg, does not ‘un-register’ it: sample_app_ota.cfg only provide means of registering additional images.
    When a new OTA image is registered with the OTA Server, the server keeps the registration details in an internal ‘database’ on the filesystem. This way, it can resume operation with the same images following a reset. Another ‘database’ file is used to save the current status of the OTA server (e.g. enabled/disabled).

    The easiest way to ‘un-register’ previously registered images without needing to modify the code is by using the following procedure:
    - Bring down the servers (e.g. press ‘k’ from the sample app)
    - Delete the OTA image database - DbUpgradeList.csv
    - Delete the OTA status database - DbUpgradeCtxt.csv
    - Restart the servers normally (run zigbeeHAgw).

    For real-life applications, the database should not be altered manually, of course. The correct way to unregister an OTA image is to use the OTA_UPDATE_IMAGE_REGISTERATION_REQ API, setting the RegisterUnregister argument to 0.
  • Jason,
    Thanks for those tips, I think they helped me rule out a few things and get a better handle on how the OTA process works. In my case it turns out that I was running the sample app from the wrong directory. The result was that the sample app appears to not have had access to either the sample_app_ota.cfg file and/or the DbUpgradeList.csv and DbUpgradeCtxt.csv files. The fix for me was to navigate to the directory with those files before running the script to start the sample app.

    Also just as a note, once I got this working I was able to conduct a successful OTA using a file with the extension ".ota", so it appears to me that ".zigbee" may not be a hard requirement.

    Best,
    Jim Mather