• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 261 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652RSIP: Zigbee OTA Update Stuck at ~60% (Off-chip OTA, Zr_Genericapp example)

Sushmitha Ramasamy
Prodigy 40 points

Part Number: CC2652RSIP
Other Parts Discussed in Thread: Z-STACK, , SYSCONFIG

Hi Team,

I am facing an issue with Zigbee OTA where the firmware update consistently gets stuck around 60, some timwe 20, 45,49, 11,3  progress.

Setup Details:

  • Device: Custom hardware based on CC13x2/CC26x2
  • Example used: zr_generic (modified for OTA off-chip)
  • OTA Type: Off-chip OTA
  • External Flash: Configured and verified
  • OTA Server: Working (same image works with zr_sw_ota_client_offchip example)
  • Stack Version: Z-Stack 3.x (please specify exact version if needed)

Observed Behavior:

  • OTA starts successfully and progresses normally up to ~60%
  • After that, progress stops and does not resume
  • Device does NOT reset during OTA
  • No button or application activity is observed during OTA (seems blocked)
  • In some attempts, it also gets stuck at very low percentage (~0.01%)

What I Have Tried:

  • Verified external flash configuration and linker settings
  • Compared with zr_sw_ota_client_offchip (working case)
  • Ensured correct inclusion of OTA clusters (inCluster)
  • Checked status poll delay (no change in behavior)

Questions:

  1. What could cause OTA to stall at a specific percentage like ~60%?
  2. Are there any known issues when enabling OTA in zr_generic compared to zr_sw?
  3. Could this be related to buffer size, block request handling, or timing (e.g., status poll delay)?
  4. During OTA, is it expected that the application loop is blocked (no button response)?

Any guidance on debugging this issue or specific areas to check would be very helpful.

Thanks in advance!

  • 0
    TI__Guru**** 223147 points

    Hi Sushmitha,

    Just so we have baselined, you have already confirmed on your system that the zr_sw_ota_client_offchip example performs an OTA update to completion?  Have you verified this on LaunchPads or with your custom hardware?  If you were to test the modified zr_generic on a LP-CC2652RSIP using the Z-Stack User's Guide instructions, what is the result?   What SimpleLink F2 SDK stack version are you referencing?  Also, what is the external flash memory device on your custom hardware?  Do you have any debugging logs or call stack analysis of the OTA once it has failed, for example what does the UI report or can you add additional prints inside of ota_client.c (otaClient_UpgradeComplete should contain status ZOtaAbort).  Can you capture the over-the-air traffic with a sniffer device?

    Sushmitha Ramasamy said:
    What could cause OTA to stall at a specific percentage like ~60%?

    It sounds like it can exit at multiple different percentages, indicating a possible Zigbee packet communication failure.

    Sushmitha Ramasamy said:
    Are there any known issues when enabling OTA in zr_generic compared to zr_sw?

    Not when the "Adding Client Functionality to an Application" guide is followed in its entirety.  And I don't have knowledge of your external flash memory device.

    Sushmitha Ramasamy said:
    Could this be related to buffer size, block request handling, or timing (e.g., status poll delay)?

    You would need to closely compare the configuration differences between zr_generic and zr_sw as they should be identical.

    Sushmitha Ramasamy said:
    During OTA, is it expected that the application loop is blocked (no button response)?

    No, the application should still be running while the OTA is being performed.  This will need to be further explored concerning how tasks are initialized.

    Here is the Zigbee Over-the-Air (OTA) Upgrades SimpleLink Academy Lab for your reference.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    Hi Ryan,

    zr_sw_ota_client_offchip example works in both  LP-CC2652RSIP and custom board which I tested successfully. when ever I checked with the zr_genericapp example, OTA process starts successfully stuck at some percentage 60%. that means not getting any error or not exiting or not failing. it stay at 60% forever. 

    controller is cc2652r1f

    flash is w25q80dv

    zr_genericapp is giving same behaviour for custom board as well as  LP-CC2652RSIP.

    Regards,

    Sushmitha

  • 0 in reply to Sushmitha Ramasamy
    TI__Guru**** 223147 points

    Although no fail state is returned, when you pause the OTA application in the debugger what is the condition of the call stack?  Is there any indication of stack overflow or heap issues?  Here is a Debugging Guide.  Can you perform a diff compare between your working and non-working versions to determine any crucial stack or heap configuration changes, along with SysConfig or linker command file differences.  Did you follow the "Adding Client Functionality to an Application" guide I referenced earlier?

    Regards,
    Ryan