• State Resolved
  • Replies 2 replies
  • Subscribers 83 subscribers
  • Views 79 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28P550SG: Adding variables during multiple LFU

zhang zhengyang
Prodigy 20 points

Part Number: TMS320F28P550SG

Hi,expert.

During multiple LFU processes, I encountered this problem: Firstly, the variable g_u32Bank1NEW12 was added; then, during the second upgrade, the variable g_u32Bank1NEW10 was added. After the second upgrade, the address of the variable g_u32Bank1NEW12 was sent out incorrectly. How should we design to solve this problem.

The first upgrade:

1.png

3.png

5.png

The second upgrade:

2.png

4.png

6.png

  • 0
    TI__Mastermind 19080 points

    Hello,

    zhang zhengyang said:
    After the second upgrade, the address of the variable g_u32Bank1NEW12 was sent out incorrectly. How should we design to solve this problem.

    Do you intend for g_u32Bank1NEW12 to retain its previous address? You would need to use the "preserve" attribute. “preserve” is used to maintain the addresses of common variables between firmware versions. “update” is used to indicate new variables that the compiler can assign addresses without constraints and also initialize during the Compiler’s LFU initialization routine, named __TI_auto_init_warm().

    Best,
    Matt

  • +1 in reply to Matt Kukucka
    TI__Mastermind 27855 points

    Hello Zhang,

    I want to highlight a few key points here:

    1. Can you please specify the compiler version you are using? Compiler version 22.6.2.LTS fixes a number of LFU bugs and is highly recommended for customers implementing LFU. Additionally, 25.11.LTS not only implements the aforementioned bugs, but also implements a new LFU mode called "all", which can be enabled by setting --lfu_default=all (and is also the default setting if --lfu_default is not assigned). In this mode, the user does not need to explicitly set variables to preserve or update. The compiler handles it for the user. Refer to Table 2-1, description of --lfu_default=all in the user guide for details https://www.ti.com/lit/spru514

    However, if an older version of the compiler is being used, and the user cannot switch for some reason, then the recommended mode is --lfu_default=preserve. With this mode, there is no need to mark existing variables as "preserve". However, new variables need to be marked as "update". In your specific example, g_u32Bank1NEW12 would need to be marked as "update" for the 1st LFU, but that variable should not be marked as "update" for the 2nd LFU (the attribute should be simply removed). For the 2nd LFU, where g_u32Bank1NEW10 is added, it should be marked as "update", but for the 3rd LFU it should not be marked as "update". 

    With "update" variables, the compiler's __TI_auto_init_warm() will manage initialization of those variables during LFU, without the need for initialization during LFU in user code.

    Using 25.11.0.LTS with --lfu_default=all saves you the additional trouble of specifying variable attributes.

    2. All of the above applies to C28 side variables. For CLA side variables i.e. those defined and used in .cla files, there are some limitations. At present, these are not documented in the compiler user guide (spru514), but this will be addressed in a revision. The limitation is that for LFU and CLA side variables, only "preserve" is supported, "update" is not supported. In other words, for CLA side variables, the compiler can handle keeping existing variables at the same addresses during LFU without re-initializing them. However, for new CLA variables introduced during LFU i.e. "update" variables, the compiler will not perform initialization in __TI_auto_init_warm(). This has to be handled in user code.

    As such, for CLA "update" variables, the "update" attribute should not be applied.

    3. Also note that in general, DATA_SECTION use with LFU needs to be carefully handled. There are many scenarios, depending on the specific use-case the compiler may issue a warning/error. As a simple example, you cannot specify a DATA_SECTION for a variable and also specify it with an "update" attribute.

    Again - all of these are correctly handled in 22.6.2.LTS (and later), so please move if you haven't already.

    Thanks,

    Sira