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.

CC1312PSIP: TOAD vs separate stack and application images

Part Number: CC1312PSIP

Tool/software:

Hi,

I am developing an OTA update solution based on the TI OAD for TI15.4. I want to minimise the OTA payload size so intend to make use of TOAD. 

Should I also use a separate binary image for the TI15.4 stack and my application so that OTA updates can be reduced in size given that the application will most likely need updating more regularly than the stack, or will TOAD actually take care of this and only update the application changes?

In other words, is there a need to use separate stack and application images if using TOAD?

Thanks for your help,

Andy

  • Hi Andrew,

    I'm not sure if I can follow you completely.

    The TI 15.4-Stack OAD is implemented as described in the User's Guide here: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_8_30_01_01/docs/ti154stack/html/ti154stack-guide/oad-secure-index.html

    The Linux Gateway SDK provides the example of an OAD Server.

    By default in the example the OAD client (sensor) will request the OAD packets and after receiving the whole binary it will boot in the new image.

    Could you please clarify for me how you want to split the application?

    In the boot process the start address for the application is stored in the CCFG. If you would like to split your application that is running on the chip you would need to implement a mechanism in this application (I would suppose this would be in your suggestion the "stack application") that it starts another binary stored at a different address (your "application").

    Is this what you are trying to do?

    Kind regards,
    Theo

  • Hi,

    Thanks for your reply. I have implemented a TI15.4 OAD server myself on a CC1312PSIP using the rfOADServer and Linux examples as reference. It currently works on OAD, and I am about to add the TOAD functionality to speed up the update process.

    I have seen in oad_image_header.h that there are the options to define a separate application image from the stack image. 

    /*!
     * OAD user application image
     *
     * A user application of split app/stack type
     */
    #define OAD_IMG_TYPE_APP                  1
    
    /*!
     * OAD stack image
     *
     * An OAD enabled stack image of split image type
     */
    #define OAD_IMG_TYPE_STACK                2

    I am wondering if there's any benefit to separating a single stack/app image into two images as it will mostly only ever be the application code that needs updating, and so therefore the update will be smaller. I might have several hundred nodes that need updating.

    It may also be the case that TOAD is sufficient and so there is no point separating the application from the stack (if that's even possible) as the TOAD process will only produce a file with differences. I haven't tried TOAD yet.

    Sorry, it's a little tricky explaining my question but hopefully this helps,

    Andy

  • Hi Andrew,

    thank you for the additional details, now I understand.

    Splitting the image in application and stack is an option that is only supported for BLE.

    But you are fully correct on the TOAD. This will allow you to only update the software changes instead of the whole application. I would recommend you to move forward by porting TOAD instead of looking for a way to implement splitting the image.

    Kind regards,
    Theo