TMS320F280049: Global variable not initialized after LFU

Hello Hang,

The LFU expert is out-of-office until January 5th, please allow until then for him to reply.

Hi Sira,

Sorry for the ambiguity in the previous description, allow me to clarify customer's use case:

• They are using their own boot loader and app, instead of following TIDM-02011.
• They are using coff
• They are using compiler version16
• After the app image is downloaded, it jump to code_start, and c_int00 will be called in the process.
• If they do POR after update, the static variable will be initialized normally.

I understand that c_int00 is not meant for this use case, however, it does contain steps copying data from .cint to .ebss. Any idea why cint_00 is not initializing the global variables? Since a POR will initialize the variables properly, by any chance the initialization in c_int00 is bypassed when it's called without POR?

Or, as a quick fix we can provide to customer, is there any recommend ways to manually copy data from .cint to .ebss and initialize the variables?

Thanks,

Hang.

I am out of office and will be back Jan 2.

Thanks,

Sira

Hang,

I am checking with a compiler expert on your question - about why c_int00 on LFU does not initialize variables.

However, as I mentioned before, c_int00 on LFU would not be correct, TI_auto_init_warm() is what should be used.

Can you tell me why this is not being used? Why the insistence on using c_int00?

c_int00 on LFU may not functionally work as expected since they would be initializing preserved variables as well. So the application behavior would likely be affected.

Thanks,

Sira

Hi Sira,

Actually, they are trying TI_auto_init_warm() too. They simply called this function in main() and it's not reinitializing the static variables. As I understand it, using this function requires following the LFU process in the TIDM-02011, which includes setting "update/preserved" attributes and providing a reference image. These features require a compiler later than version 21 and is limited to eabi, but they are using version 16 and coff. 

I offered them a temporary patch where I extracted part of the c_int00 assembly codes that copies .cinit to .ebss and run them in main(). Doing so can reinit the variables properly but will causes glitches later in their application codes. 

So we are trying both solutions here. If we can get TI_auto_init_warm() working properly, that will be surely better than the temporary batch. What is required to get TI_auto_init_warm() works properly?  You may assume all variables need to be "updated" , none of them is "preserved", and they don't require the application to run normally during update.

Thanks,

Hang.

Hi Hang,

Correct, to use TI_auto_init_warm(), you need the later compiler versions and it works with EABI only. You can refer to 2.3 of spru514. The compiler requires the following:

- a reference image to be specified using --lfu_reference_elf=

- specifying the lfu_default mode. If nothing is specified, it assumes "preserve" mode i.e. the compiler preserves all global and static symbol addresses found in the reference ELF executable unless __attribute__((update)) is specified for a symbol. Initialization is performed only for symbols with the __attribute__((update))

If "none" is specified as the mode,  the compiler preserves only the addresses of symbols that have __attribute__((preserve)) specified. It re-initializes symbols that have __attribute__((update)) specified. All other global and static symbols can be allocated to any memory address by the linker, but are not re-initialized when a warm start occurs.

In your use-case, you want all the variables to be "update". However, both the modes above require __attribute__((update)) to be specified for initialization to be performed. Also remember that a reference image should be specified.

So the LFU should occur without a POR, but it is ok for application to not run normally during update? Just curious - which customer is this, and what is the end application?

Thanks,

Sira

Hi Sira,

Although the customer raises this as a LFU issue, we find out later that the customer doesn't need the application running normally during update. At this point, I think "LFU" is not appropriate description of their case anymore. It should be just DFU. Sorry for the mislead.  

From your description, I conclude that, To get TI_auto_init_warm() to work properly, they'll have to change their compiler version and re-generate their application and reference image using eabi. This will be very risky, since they are looking at 1M+ device operating on grid. 

If this is considered as DFU instead of LFU, many requirements would be relaxed.  In this case, is there any recommended way to do the re-initialization while keeping the compiler version 16 and coff format?

Thanks,

Hang

Hi Sira,

This problem is solved by correcting the way they declare global struts,

They old way is like:

static struct x={0};

After correcting this, the static variables are reinitialized after jumping back to codestart after the image download and without any additional steps.

Thanks,

Hang