• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 115 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: C++ Compiler generated __sti functions not copied into RAM before constructor is called

Falk Sobe
Prodigy 20 points
Part Number: TMS320F28388D


Tool/software:

Hi,

I found very little information about the compiler generated "__sti__" functions.
I have some sections of code, which are loaded into RAM before main() (binit table).
If I have a global constructor which is also loaded into the RAM section, the program crashes, because the linker does not copy the __sti__ functions into RAM before calling the constructor.

I try to simplify the structure of the code:

main.cpp -> running from flash

#include "ram_funcs.h"

static MyClass myInst = MyClass();

int main()
{
...
}

ram_funcs.h

class MyClass
{
    MyClass();
}

ram_funcs.cpp -> running from RAM (LOAD=FLASH RUN=RAM)

MyClass::MyClass()
{
...
}

The linker puts the object from "ram_funcs.cpp" into the binit table, but not the __sti__ function.

  • 0
    TI__Guru**** 250490 points
    Falk Sobe said:
    I found very little information about the compiler generated "__sti__" functions.

    Please read the latter part of this forum post.  Focus on understanding the part about the functions, auto-generated by the compiler, which invoke the constructor on a global instance of a class.  These are the __sti__ functions.  

    To avoid a possible point of confusion ... That forum post is old.  It describes the pointers to the __sti__ functions as residing in the section .pinit.  This is true in the older COFF ABI.  It is very likely you use the newer EABI.  Under EABI, the section name .init_array is used instead of .pinit.

    Falk Sobe said:
    If I have a global constructor which is also loaded into the RAM section, the program crashes, because the linker does not copy the __sti__ functions into RAM before calling the constructor.

    The constructor function MyClass() resides in RAM.  It is copied there from FLASH during system startup.  All such functions are copied from FLASH to RAM before any __sti__ functions are called.  I presume the related __sti__ function is in FLASH, just like main.  This __sti__ function is called during system startup.  In turn, it calls the constructor MyClass(), which is in RAM.  This may be slower than optimal, but I don't understand why it causes a crash.  Does MyClass() call anything else?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 20 points

    Hi George,

    thank you for your answer :)
    I tried to simplify the problem, and forgot, that many modules are loaded manually into RAM as well.
    The program is our boot loader.
    We reserved very little space for it in the internal flash. The rest of the boot loader gets loaded into RAM from an external Flash in the main.cpp

    updated structure

    - main.cpp -> LOAD/RUN internal Flash
    - programFlash.cpp -> LOAD internal Flash, RUN RAM
    - fw_update.cpp -> External Flash, manually loaded to RAM after in main();

    In fw_update I wanted to use a global constructor of a class in programFlash.
    This didn't work, because it is manually loaded along with the __sti__ function.

    I wanted to link parts of fw_update into the internal flash, so that the instance get initialized before calling the main().
    I now got rid of the global constructor and initialize the instance later in the main.

    Thanks,

    Falk