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.

CC2538: OTA update fails

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK, CC2652R

Hello,

I want to perform an ota update to a heiman device (it uses nxp chip) from my coordinator. I have been provided by heiman an update file which ended in .ota and told me to rename it to .zigbee. OtaServer app recognizes the file and its attributes correctly. But when I try to initialize the update it sometimes sends one block, others it doesn't send anything and I get a default response indicating failure.

I contacted Heiman and told me they tried the update and it works and it also works with their other clients. I have tried to do the update with two different chips (cc2538 and cc2652r1) and two zstacks (1.2 and 3) and it only doesn't work with the heiman sensor (other updates to other devices in the ti family work as expected). They sent me a sniffer file to see if I do something wrong and I also sent them mine to compare it.

They made this notes:

Here are both sniffer files (NwkKey for mine is: 5ccab957319e97c86f36ad76fe86c2a2)

In the Heiman file, the OTA process starts at packet 47.949

Can someone help me figure out why it doesn't work?

  • Hello Panagiotis,

    The CC2538 OTA Dongle/Server implementation uses its own zclOTA_SeqNo inside zclOTA_ProcessImageBlockReq -> zclOTA_Srv_ImageBlockReq -> zclOTA_SendImageBlockRsp -> zcl_SendCommand which it increments from zero.  You could try to modify it so that it uses the zclIncoming_t hrd.transSeqNum starting from zclOTA_ProcessImageBlockReq.  I would expect the CC26X2R1 OTA server to behave differently than shown since it does pass along the existing transSeqNum from the incoming Image Block Request.  This code was modified in SimpleLink CC13X2/CC26X2 SDK v4.10 (as shown in Z-Stack Release Notes fixed issue ZIGBEE-683) after addressing a similar E2E thread.

    Regards,
    Ryan

  • I modified it and it still didn't work. I traced the reason back to zclOTA_ServerHandleFileSysCb. It does not enter this case

    #if (defined OTA_SERVER) && (OTA_SERVER == TRUE)
            case MT_SYS_OTA_MSG:
              zclOTA_ServerHandleFileSysCb ( ( OTA_MtMsg_t* ) MSGpkt );
              break;
    #endif

    and it causes zclOTA_Srv_ImageBlockReq to return ZCL_STATUS_NO_IMAGE_AVAILABLE.

    What causes this?

  • I don't understand your comments regarding zclOTA_ServerHandleFileSysCb since the server application should be capable of entering this function and I recommend that you further debug inside this location.  However, if zclOTA_Srv_ImageBlockReq is exiting with ZCL_STATUS_NO_IMAGE_AVAILABLE then this indicates that the fileId.version settings are incompatible between the existing application and candidate image.  Do you have “Version Check Image File” selected in the Options menu of OtaServer.  This will refuse an OAD update if the candidate is not a higher version than what is already stored on the device.  You can further check the OTA Upgrade section of the Z-Stack User's Guide and compare the .zigbee output file contents to make sure that Zigbee formatted binary has a compatible Zigbee OTA header which is expected by the OtaServer desktop application.

    Regards,
    Ryan

  • With cc2652r the update starts with "Version Check Image File” selected but with cc2538 it hits ZCL_STATUS_NO_IMAGE_AVAILABLE 

    queryResponse.fileId.version has a value of 0 when it should have 0x17

  • The SimpleLink CC26X2R and Legacy CC253X OTA server project code bases have diverged for several years now.  You can compare them to determine crucial differences in application execution.

    queryResponse.fileId.version is populated by the *.zigbee file's header information as provided from the host, indicating that the format could be incorrect.

    Regards,
    Ryan