MSPM0G3519: Live firmware update (LFU) examples

Hi, Wayne

For the "reset", there are two condition:

1. Using reset to jump from boot code to app code when startup or update is finished.

2. Using reset to enable the dual bank swap feature, this reset is called by init_done function in boot code, this feature is related to customer security code.

Wayne Huang said:

Q1: As there are two flash banks, MSPM0G3519 should be able to do live firmware update (LFU) with reset and without reset. Is it right?

See description above.

Wayne Huang said:

Q2: Would you please show us where to get an example for live firmware update "with" reset? This is also called OTA update in the datasheet below.

https://dev.ti.com/tirex/explore/node?node=A__APjkYg9RWxwM6nRUc3InzA__MSPM0-SDK__a3PaaoK__LATEST

BIM is for G3507.

And CSC is for G3519 dual bank.

For Dual bank handle, there is a internal demo for your reference.

But, assert init_done will trigger reset.

G3519_Bank_Swap_Demo_V2.1.zip

Wayne Huang said:

Q3: Would you please show us where to get an example for live firmware update "without" reset? 

Just directly jump from boot to app is OK, there is a jump example in BSL code:

C:\ti\mspm0_sdk_2_04_00_06\examples\nortos\LP_MSPM0G3507\bsl\secondary_bsl_uart

BSL is for image update and program to Flash, and BIM and CSC is for image management.

Regards,

Helic

Hi Helic,

For Q3:

How can we guarantee the preserved global/static variables are kept in the same memory location before, during and after firmware update?

Hi, Wayne

We can use the variables in boot while running in app.

Also, directly jump from boot to app will not clear the SRAM, customer can use the fix address to save some parameters.

And this kind of application depending on customer's requirement.

Regards,

Helic

Hi Helic,

In C2000, compiler can support preserved global/static variables by default or uses attribute to handle fix addresses, so the user does not need to handle fix addresses.

float32_t __attribute__((preserve)) BUCK_update_test_variable1_cpu;

float32_t __attribute__((update)) BUCK_update_test_variable2_cpu;

Compiler also has a warm initialization (called __TI_auto_init_warm) to initialize the global/static variables that are new in the new image referring to the old image.

4.4 LFU Compiler Support in

https://www.ti.com/lit/pdf/spruiu9?keyMatch=SPRUIU9&tisearch=universal_search

Does MSPM0 compiler has similar functions?

Hi Helic,

You said "directly jump from boot to app will not clear the SRAM, customer can use the fix address to save some parameters."

1) When it jumps from boot to app, do you mean there are two projects (boot project and app project) and you mean jumps from boot project to app project entry point _cint00? But since it jumps to _cint00, doesn't it mean the run time support library (RTS) will initialize all global/static variables, which is not desired in LFU without reset. 

C2000 compiler uses a warm initialization (called __TI_auto_init_warm) rather than _cint00 so that it only initializes these global/static variables in attributes  __attribute__((update)) and keeps __attribute__((preserve)) in the same memory locations without initializing them.

2) The user uses TI ARM clang. Since TI ARM Clang does not support warm initialization or similar, would you please show us how to write codes to place global/static variables in fixed RAM so that both old and new images can access them? How does the user do to prevent the compiler from initializing them?

3) How does the user handle different interrupt vectors here? That is, the old image still runs with its interrupts, but the new image runs with its new interrupts. What if there are different interrupts in old and new images? How do we handle switch over here?

Do we have any doc/example to show these?

Hi Helic,

Thank you for your information.

I will discuss with the customer and then discuss you further offline in a real example if needed.