TMS320F28P650DH: Does LFU solution supports c++ or c only?

Hang,

I believe the compiler supports LFU with C and C++.

I have added the compiler SME for confirmation.

Thanks,

Sira

Hang,

The lfu implementation supports both c and c++.  Is there some issue with c++?

Regards,
Greg

Greg & Team,

The customer has followed up offline with this please:

" 

I need your further help on the LFU function. We are considering one question: you know all variables of one class are put together in the flash, their addresses are consecutive. If we add new variables to one class when doing firmware upgrade, how will LFU compiler deal with the new variables? Because according to datasheet of LFU, all old variables will not be re-allocated. Only new variables will be assigned addresses. But for class, all variables should be together. 

"

Further input is welcomed and  appreciated.

TY,

Chris

Chris,

For LFU, in the new LFU executable, attribute(preserve) variables are kept at the same address as the input reference executable. For new variables marked with attribute(update), the compiler groups them all into the .TI.update output section which users must add to their linker cmd files.

In order to place new variables adjacent to older variables they will need to mark those variables with location attribute (and not with update attribute). However, this means that the lfu warm_init will not be done for those new variables in which case they will need to manually initialize for warm init switch over.

They should also be using 22.6.2.LTS which has the latest LFU updates.

Thanks
Greg

Appreciate the quick reply and further clarification here, Greg.  I've also followed up with the customer offline via email.  Let's just give it another day or so before we close this thread out....awaiting further feedback/confirmation.

Thanks!

-Chris

Greg,

Additionally:

"

Thank you so much for your support. I just want to be more clear about this. For example, I have two classes A and B and they both have many variables for the first version. And their addresses are consecutive. When I upgrade the firmware and want to add a new variable for class A, the start address of class B will change from 000180a0 to 000180a4 in the normal way of firmware upgrade. And all code after class A will be reallocated because of this new variable. But in the case of LFU, all reserved variables will stay at the same address with old version. That means the class A and class B should stay at their old addresses and no reserved space for the new variables of class A. Then how will LFU handle this new variable of class A? If it is settled to .TI.update output section, how can it be linked to class objA? If not, what is the solution? And I am not clear about the location attribute you mentioned. I can't find this attribute in any documents I download about LFU. Could you send me a link of the file that explains this? Thank you.

First Version:

class A

{

    public:

        float f_A1;

        float f_A2;

        ……

};

class B

{

    public:

        float f_B1;

        float f_B2;

        ……

};

Address:

1     0001808e  objA                                                                                  
1     000180a0  objB 

Upgrade Version:

class A

{

    public:

        float f_A1;

        float f_ANew;

        float f_A2;

        ……

};

class B

{

    public:

        float f_B1;

        float f_B2;

        ……

};

1     0001808e  objA                                                                                  
1     000180a4  objB 

 "

Regards,

Chris

Please see user guide spru514 pdf for attribute(location) details. 

LFU cannot both preserve addresses from the old firmware, and insert new variables where there is no space. You would need to somehow allocate holes in your memory map to accommodate adjacent growth.  

LFU can however ensure that variables in the old firmware remain at the same address such that warm-init state transitions do not need to reinitialize those variables.

You could alternatively mark all the variables in class A and class B as attribute(update) in which case they will move in the new firmware and also will be warm-initialized during switch over.