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.

CODECOMPOSER: Issue with initializating data when calling a function running from ram: _system_post_cinit() error

Part Number: CODECOMPOSER


Platform:

Device: F28379

CCS: Version: 11.1.0.00011

Compiler TI v21.6.0.LTS

I have an issue when using constructors (or any data that is initialized before running to main) that call a function that is set to run from RAM.

Details:

If I have an object that calls a run-from-RAM-function on initialization,the system will crash on startup. Since the init occurs before main is reached, the function has not been moved to ram yet. As such: a _system_post_cinit() error occurs.  The code works as expected without having a separate run location.

I would say that this is expected behavior, but certainly unwanted.

  1. One way to fix this is to not run the function from RAM. This would be a bit of a pain to keep track of if multiple functions are doing this.
  2. Another way to fix this is to do the initialization after the memcpy function, but this would require pushing to the heap if the data needs to be const. (which it does in my case).

I would like a graceful work around. Any guidance is appreciated!

Example (Psuedo) Code:

class Demo {
private:
int i;
int j;
public:
GetI();
GetJ();
}
Demo::GetI() {return i;}

CODE_SECTION("RunFromRam");
Demo::GetJ() {return j;}

Demo A;  // Demo A is instantiated before being used.

const int X= A.GetI(); // Works as expected
const int Y= A.GetJ(); // Crashes on Init

  • William,

    Sorry for the delayed response from our side, for some reason I didn't see this thread on Friday.

    I'm going to ask others, but I was thinking that a brute force approach to this issue would be to modify the CodeStartBranch.asm file before the cinit is called. 

    You would have to know where this section is getting placed and manually(and with ASM instructions) move those opcodes to the locations they need to be in.  This doesn't sound very practical or re-usable to me, but wanted to  throw it out there while I research this a bit more.

    I'll try reply again tomm with any updates.

    Best,
    Matthew

  • Hello Matthew,

    Thank you.  I was hoping that you had a "Best practices" for this type of situation as I imagine that I am not the only one who has encountered this.

    Here is the situation where this could be a global issue:

    1. Using C++, specifically classes for individual modules
    2. Standard practice for C++ dictates initializing members in the constructor, in fact, this is the only place where constant members should be initialized.
    3. Standard practice has all of the members set as private and manipulated through accessor/mutator functions (gets and sets).
    4. In the case where one of your classes is for critical control, you would want this to run-from-ram for best performance.
    5. Since there may be a lot of functions (due to #3 and others), the most efficient way is to set the entire obj file for the critical class to run-from-ram.
    6. However doing #5 would also set the constructor to run-from-ram, leading to the issue described above.
    7. Because #3 implies many functions (ignore inlining for now), whitelisting run-from-ram is cumbersome and error-prone.
      1. With that said, setting the entire obj except the constructor (and related) to run-from-ram (i.e. black-listing), could be reasonable... I tried to find a solution for this, but could get it right.
      2. Another solution is having two cpp files for each class, one set to run-from-ram and the other left default. I started doing this before writing this post, but it just felt like I was over-complicating it.

    FYI, this was a pain to debug; when this crash occurs there is no indication of where it occurred,i.e. no stack frame to analyze. I had to assembly step from cinit to get an idea of what was going on and since most of the code running from flash, the breakpoint limitation was not fun to work around.