• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 801 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.

CC2652R: zr light fota works when connecting to zc ota server but not when we use 3rd party upgrade tool

Walter Macamos
Genius 5345 points
Part Number: CC2652R
Other Parts Discussed in Thread: UNIFLASH, FLASH-PROGRAMMER, Z-STACK, SIMPLELINK-CC13X2-26X2-SDK

Hi TI Team,

My Zr light  ota client can work after basing from zr switch ota client sample.

It can pair to zc ota server and do the fota completely.

But, out goal to make it work for 3rd  part gateway like Phoscon

. 

Regards,

Walter

  • 0
    Genius 5345 points

    Hi TI Team,

    The sniffer log says the  fota completed trasfer of  BEBE-2652-00000001.zigbee as show n in sniffer log.

    But, my device not properly updated, and not booting properly. Is there a wat to combine the BIM offchip firmware with the zr light code to 1 firmware so 1 loading only?

  • 0 in reply to Walter Macamos
    Guru 735685 points

    Basically, OTA would only update application not including BIM. Do you use sniffer to check what happens over the air? By the way, you can also set breakpoint in your device application code to locate where the problem is.

  • 0 in reply to Walter Macamos
    TI__Guru**** 217937 points

    Hi Walter,

    You can compare the sniffer log of the working OtaServer/ZIGBEE-LINUX-SENSOR-TO-CLOUD session versus the third-party gateway to help determine where the difference lies.  Perhaps the generated .zigbee file format is not interpreted in the expected manner as previously.  As YK mentioned, not booting properly could imply an issue with the BIM.  The BLE Enhanced OAD SimpleLink Academy Lab provides instructions for creating a production image but I agree with YK that the BIM is not updated OTA with the application.  This is furthermore discussed in the Z-Stack User's Guide.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5345 points

    Hi YK/Ryan,

    I compared the sniffer log of:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/feb02_5F00_zr_5F00_light_5F00_otaclient0x13c6_5F00_to_5F00_zc_5F00_demo_5F00_board.7zhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/feb02_5F00_zr_5F00_light_5F00_otaclient0xa947_5F00_to_5F00_3rd_5F00_party_5F00_gw.7z1. zr light ota client to  zc server in a demo board - working properly

    feb02_zr_light_otaclient0x13c6_to_zc_demo_board

    2. zr light ota client to  3rd party gateway.

    feb02_zr_light_otaclient0xa947_to_3rd_party_gw - not rebooting

    Regards,

    Walter

  • 0 in reply to Walter Macamos
    TI__Guru**** 217937 points

    Walter,

    The demo_board sniffer log aborts the OTA upgrade (packet 29277), I would not consider this as working properly.  The image sizes are the same in each so I'm not sure what is wrong with the image such that party_gw finishes the upgrade but cannot boot properly afterward.  You can read the flash memory content in UNIFLASH or FLASH-PROGRAMMER for each and compare the differences, and review the Z-Stack OTA Upgrade documentation.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5345 points

    Hi Ryan,

    The demo board upgrade went 2 time ota upgrade.

    The ota upgrade already finished in packet 28734 that is why abort issued for next upgrade from ota server application.

    I  noticed also that the gateway log the ota image  requested size is 32 but reply is 28.

    I will compare themem data after ota for 2 cases then we let u know.

    Regards,

  • 0 in reply to Walter Macamos
    TI__Guru**** 217937 points

    Hi Walter,

    Thanks for pointing out the packet which I had missed.  The start and end of your OTA transfer appears to be the same in either instance.  It should be fine for the server to return image blocks smaller than what is requested but perhaps you can change the request size from your client to observe whether the behavior changes.  Please let us know when you've been able to compare the flash memory contents.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5345 points

    Hi Ryan,

    There is a difference between 3rd party gw and  zc ota demo board.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/158/memory-comparison.7z

  • 0 in reply to Walter Macamos
    Genius 5345 points

    Hi YK,

    Any idea about this one?

    Regards,

    Walter

  • 0 in reply to Walter Macamos
    Guru 735685 points

    Do you use the same OTA file which works with z-stack OTA server but it doesn’t work on 3rd party gateway?

  • 0 in reply to YiKai Chen
    Genius 5345 points

    Hi YK,

    Yes, same ota file.

    Regards,

    Walter

  • 0 in reply to Walter Macamos
    Guru 735685 points

    Do you see "Update End Request" sent from your device and 3rd party gateway respond "Update End Response"?

  • 0 in reply to Walter Macamos
    TI__Guru**** 217937 points

    Hi Walter,

    The difference in flash comparison concerns the NV memory, to_zc_serverdemobd.hex starts at 0x48000 whereas to_3rdpartygway.hex starts at 0x54000.  It is important for the application to know where the NV memory resides and this discrepancy is most likely causing the boot issues.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 5345 points

    Hi Ryan,

    We are running same firmware and BIM.  As we know,  The start address is set in FW already.

    I check our ota tool is not setting nV start address or dont have means to change start address.

    Regards,

    Walter

  • 0 in reply to Walter Macamos
    TI__Guru**** 217937 points

    The OTA image candidate typically does not overwrite the NV memory, this way the device retains network information and is able to rejoin after an update.  The OTA application does however need to know where the NV contents are located.  The flash area of NV is determined when building the application firmware.  

    More information is required to determine where the inconsistency exists in the system.  Have you tried changing the OTA block request size?  Does the same node/firmware which fails to be updated with the third-party OTA server succeed when using the TI tool?  Are you able to use the third-party setup to update a default SIMPLELINK-CC13X2-26X2-SDK v4.40 OTA client?

    Regards,
    Ryan