• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 58 subscribers
  • Views 2743 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.

CC2650: ZStack OTA update Issue.

Mars
Prodigy 160 points

Part Number: CC2650
Other Parts Discussed in Thread: Z-STACK, SYSBIOS, CC2640, CC2530, CC2538

ZStack Version : Z-Stack_Home_1.2.2a.44539 (CC2650)

The ZStack must use internal flash address : 0x100 ~ 0x5F0 (SYSBIOS ROM?), and we can't move to other internal flash page.

We have been completed the bootloader for ZigBee. But it has risk in OTA update process when update address : 0x100 ~ 0x5F0.

I think if the data section (Address : 0x100 ~ 0x5F0) in page0 (used by ZStack) can be moved to other page or we can change boot jump address.

The problem will be resolved.

  • 0
    TI__Expert 8950 points
    Hi,

    I'm not sure I understand your concern, can you please clarify? If you look in the linker file cc26xx_app.icf (or cc26xx_app_ota.icf if you are using that package), when you are using TI-RTOS in ROM, two areas of memory are sectioned off to place some variables to interface with the ROM contents:

    FLASH: ~0x00000100 - 0x00000600
    RAM: ~0x20000100 - 0x20000200

    Any time you generate a new OTA image using this linker file, the functions above will be accounted for, so there should be no issue when doing an OTA upgrade.
  • 0 in reply to JasonB
    Prodigy 160 points
    Hi JasonB ,

    My bootloader compiled at page0 (address range : 0x00000000 ~ 0x00000FFF) , it overlap with the ROM contents in FLASH.
    So the bootloader must update itself at page0 in OTA update process. It's dangerous when power-off or hang up accidentally.

    Regards,
    Mars
  • 0 in reply to Mars
    TI__Guru**** 220717 points
    Hi Mars,

    You are correct in that this is a dangerous procedure which would overwrite the TI-RTOS flash from 0x100 to 0x600, which is why the bootloader should be compiled at the end of flash instead. You should customize the Customer Configuration Area (CCA) of your cc26xx_app.icf file to occupy the last 0x1000 of flash. Then in your bootloader project you create a cc26xx_bootloader.icf which places the flash into this custom area. RAM isn't used so there shouldn't be any overlap when combining the images. Are you using your own custom bootloader solution or starting from a package provided by TI?

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 160 points
    Hi Ryan Brown1 ,

    My bootloader refer to CC2640 BLE project. It compiled at page0 (0x00000000 ~ 0x00000FFF) and page31 (0x0001F000 ~ 0x0001FFFF). It must include TI driverlib.lib (Ex : SPI driver) , so only 1 page (4096 bytes) is not enough. My image copy function is in page31 , so it can update itself successfully.

    I have got tho ZigBee OTA example from TI and traced the example code.
    Base on my understanding the baseloader is not a bootloader(More like a function).
    It call by ZigBee OTA profile. The baseloader function start to copy image to internal flash after OTA transfer completed. It is also dangerous when power-off or hang up accidentally in image copy process.
    Is my opinion correct?
  • 0 in reply to Mars
    TI__Guru**** 220717 points
    Hi Mars,

    The mentioned solution will suffice for a flash space of 0x2000 as well.

    Since a running image cannot update itself, OAD methods must employ a bootloader designed to run every time the device resets, check the validity of newly downloaded images, and if necessary, load the new image into internal flash. TI’s bootloader implementation is called the Boot Image Manager (BIM). The baseloader is a legacy BIM implementation as there is a risk involved where a device may become bricked if a power loss is experienced while updating a page. A BIM is more complicated and therefore secure, but they are applications all the same. You can refer to the Z-Stack Home 1.2.2a OTA Upgrade User's Guide (SWRA353) for more information on the Zigbee implementation of the OTA boot loader (named the Image Boot Manager).

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 160 points
    Hi Ryan Brown1 ,

    I have been completed my BIM implementation for ZigBee OAD in CC2650, and verify process successfully. It's a strange suggestions to reference SWRA353 (CC2530/CC2538). Maybe CC2640 OAD User's Guide wiki (processors.wiki.ti.com/.../CC2640_OAD_User's_Guide) or C2640 OAD User's Guide documentation more approach ZigBee OAD BIM implementation.

    BTW , Could you tell me is it possible to change boot jump address in CC2650 or move ROM contents to other internal flash page?
  • 0 in reply to Mars
    TI__Guru**** 220717 points
    I only mentioned SWRA353 as an example of ZigBee OAD IBM resources, I agree that the CC2640 OAD UG has more information about the BIM and is a great resource for creating your own implementation. There is little that the ROM bootloader can do for your OAD application since it is stored in read-only memory and uses serial communication. This is why a BIM is implemented in flash.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 160 points
    Hi Ryan Brown1 ,

    Thanks for your detail information.
    Is it possible to change boot jump address in CC2650 or move OAD application ROM contents to other internal flash page?
  • 0 in reply to Mars
    TI__Guru**** 220717 points
    Hi Mars,

    You cannot change the jump address of the bootloader stored in ROM and there is no OAD application in ROM. The BIM used for OAD purposes must all reside in flash.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 160 points
    Thanks for your reply and support. I've noticed our customer this information. They will evaluate the risk of OTA.