• State TI Thinks Resolved
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 267 views
  • Users 0 members are here
Support feedback
Options
Options
Related

SIMPLELINK-CC32XX-SDK: Feature Request: API to trigger application start from alternative image file

uladzislau leshchanka
Prodigy 10 points
Part Number: SIMPLELINK-CC32XX-SDK
Other Parts Discussed in Thread: CC3235MODS

Tool/software:

Hello TI Team,

I’m working on a project using the CC3235MODS module and a custom bootloader. At startup, my bootloader checks for a previously downloaded and validated firmware update, which is stored in a custom file (e.g. mainapp.bin) along with a checksum or other validation metadata.

The update process does not overwrite the default /sys/mcuimg.bin, but instead stores the new firmware image in the SLFS using FileSafe or public write mode.

Feature Request:

Please consider providing an API such as:

bool sl_SetBootFile(const char* filename);

Or even just:

bool sl_TryBootFromFile(const char* filename);

This API would allow the application to notify the system that on the next reboot, it should attempt to boot from an alternative file (e.g. mainapp.bin), instead of the default /sys/mcuimg.bin.

Expected behavior:

  • Bootloader checks and validates file (e.g. mainapp.bin)

  • Calls sl_TryBootFromFile("mainapp.bin")

  • API checks if file exists and is valid, returns true

  • Bootloader then issues a software reset (via PRCMHibernateCycleTrigger() or similar)

  • Upon reset, the ROM bootloader or system attempts to load mainapp.bin instead of /sys/mcuimg.bin

Benefits:

  • Enables dual-image or staged firmware update strategies

  • Reduces risk of bricking during firmware update

  • Gives developers more flexibility with custom bootloaders (CAN, UART, etc.)

  • Allows update and validation logic to reside entirely in user space

This would be a very useful and low-risk feature that could greatly enhance the robustness and flexibility of firmware updates on the CC32xx platform.

Let me know if this is feasible or already possible via other mechanisms.

Best regards,
Vlad

  • 0
    TI__Mastermind 23146 points

    Hi Vlad,

    Thank you for the suggestions.

    We will look further into this and see if feasible and potential impact.

    PLlease note that the CC32xx SDK has been on LTS for 2+ years, which means that any updates done are strictly limited to bug fixes.

    Regards,

    AB

  • 0 in reply to AB
    Prodigy 10 points

    Thanks a lot, AB.

    I hope you find this interesting. Don’t hesitate to ask more questions regarding the use cases of this option!

    Next question:

    Do I have any chance to reduce the sl_Fs*() code size and make it as small as possible?

    Do you have a lightweight or isolated implementation that provides access to the file system, at least to public files only?

    Currently, the full library exceeds 56 KB, which is too large for my use case.

    Best regards,

    Vlad

  • 0 in reply to uladzislau leshchanka
    TI__Mastermind 23146 points

    Hello,

    The FS implementation should be part of the NWP and not a dedicated library.

    can you confirm where are you getting the 56K from?

  • 0 in reply to AB
    Prodigy 10 points

    Hi AB,

    I’ve created a minimal application.

    As you can see, the binary size is 49 KB (or 56 KB with the default stack and heap sizes --stack_size=0x1000 and
    --heap_size=0x8000 )

    int main(void)
{
    _i32 lFileHandle;
    _i32 lRetVal;
    _u32 ulToken = 0;
    _i16 iRetVal = 0;
    unsigned char BootInfo[16];


    //
    Board_init();
    //
    NoRTOS_start();
    //
    InitTerm();
    //
    GPIO_init();
    //
    SPI_init();
    Platform_TimerInit(&AsyncEvtTimerIntHandler);

    UART_PRINT("Begin\r\n");

    if((iRetVal = sl_Start(0, 0, 0)) == SL_ERROR_RESTORE_IMAGE_COMPLETE)
    {
       UART_PRINT("sl_Start Failed\r\n");
       while(1)
       {
           ;
       }
    }
    UART_PRINT("Status : %i\n", iRetVal);

    lFileHandle = sl_FsOpen((unsigned char *)"update2.bin",
        SL_FS_CREATE|SL_FS_OVERWRITE | SL_FS_CREATE_SECURE |
        SL_FS_CREATE_PUBLIC_WRITE | SL_FS_CREATE_PUBLIC_READ |
        SL_FS_CREATE_NOSIGNATURE | SL_FS_CREATE_MAX_SIZE( sizeof(BootInfo)),
        (_u32 *)&ulToken);

    if(0 > lFileHandle)
    {
        return(-1);
    }

    memset(BootInfo,0xAA,sizeof(BootInfo));

    lRetVal = sl_FsWrite(lFileHandle, 0, (uint8_t*)BootInfo, sizeof(BootInfo));

    lRetVal = sl_FsClose(lFileHandle, 0, 0, 0);
    if(0 != lRetVal)
    {
        return(-1);
    }

    lFileHandle = sl_FsOpen((unsigned char *)"update2.bin", SL_FS_READ, &ulToken);

    if(0 > lFileHandle)
    {
        return(-1);
    }

    uint8_t pData[16] = {0};
    lRetVal = sl_FsRead(lFileHandle, 0, pData, 16);
    sl_FsClose(lFileHandle, NULL, NULL, 0);

	return 0;
}

    /////////////////////

    Current settings:

    --stack_size=0x800
    --heap_size=0x800

    Best Regards,

    Vlad

  • 0 in reply to AB
    Prodigy 10 points

    Hi AB,

    I hope you are doing well.
    Have you had a chance to review the proposal?
    Do you think it would be possible to implement such options in the future?

**Attention** This is a public forum