• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 695 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.

Original question:

RTOS/CC1310: SET_CCFG_IMAGE_VALID_CONF_IMAGE_VALID is not working

CC1310: CC13XX CC26XX: Best strategy for flip-flop firmware upgrade

GregoireGentil
Expert 2330 points
Part Number: CC1310


My firmware image is smaller than half of the flash size of my CC13xx part. What is the best strategy so that I can put in place an upgrade mechanism with a flip-flop image scheme?

More precisely:

-Q1. How can I specify a start address different from 0 after a boot sequence? IMAGE_VALID_CONF doesn't seem to do the trick for CC13xx according to the TR datasheet. How can I jump to half of the total flash size after booting? There are a few threads about that question on e2e but the answer is not very clear.

-Q2. How can I define a NVS region at run-time?

let's say that firmware-v1-A is occupying the first half of the flash and is running. It has the second flash part hard-coded as NVS. Does this firmware need to get firmware-v2-B which has the first half part of the NVS hard-coded so that this firmware can upgrade at the next iteration after download firmware-v3-A? Or can I create a NVS region at run-time in the other part of the flash that is not used and modify the jump address at next boot?

  • 0
    TI__Intellectual 2180 points

    Hi,

    I'll work to find an appropriate expert to refer to too, but this may take a few days as availability is currently limited.

    In the meantime, could you comment however on how you are trying to set the IMAGE_VALID_CONF address? Does the linker file layout in the image specify the interrupt vector table at the address you are trying to jump too?   

    Regards,
    Michael

  • 0 in reply to Michael Hollister
    Expert 2330 points

    Thank you for helping. It's a pretty large question.

    The most interesting links I found are:

    https://www.hackster.io/firmwareguru/secure-ota-firmware-update-with-cc2650-e14683

    and

    http://dev.ti.com/tirex/explore/content/simplelink_academy_cc13x2_26x2sdk_4_20_00_00/modules/154-stack/154-stack_05_oad/154-stack_05_oad.html#oad-overview

    I don't think that it's a good idea to play with IMAGE_VALID_CONF. It seems better to have a fixed BIM and two storage space for the app already defined in NVS. That would solve the second question.

    I'm still unsure how the BIM can jump to one of the two apps and those apps will have their own vector table.

  • 0 in reply to GregoireGentil
    TI__Intellectual 2180 points

    If you can utilize the BIM, then I would recommend looking at a similar flip-flop OAD implementation from the CC13x0 SDK. You can review the on-chip OAD projects for additional code details for how this is achieved.

    To answer your question to how the BIM can jump to any one of two applications:

    1. The reset vector address is different for image A and image B. The documentation linked above references this in the "Creating an On-chip OAD image" section.
    2. The BIM uses inline-assembly to jump to a specific address when its decided which images in needs to boot into. You can find this logic in the bim_main.c file (inside the main function) for the on-chip BIM project. 

    Regards,
    Michael

  • 0 in reply to Michael Hollister
    Expert 2330 points

    I have read the link. Thank you. This is useful. I think that I understand.

    Is there a way to have the same image downloaded by the running AppImage and it's modified on-the-fly, especially:

    -1) an AppImage should be able to configure at run-time a NVS address to store the downloaded image in the other part of the flash. Is it possible to configure a NVS address at run-time?

    For instance, the appImage checks if it's located at 0x01000 and then configures a NVS at 0x10000 or vice-versa.

    -2) an AppImage modifies the unique 'standardized' downloaded image and overwrite the equivalent of "m3Hwi.resetVectorAddress=0x10010;"depending if it's located at 0x01000 or vice-versa.

    I think that 1) is possible but I have the feeling that 2) is going to be too complex.