• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 221 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.

TMS320F28377D: After extending the .ebss section, the initialization by cinit is effectless

Tjarko Möbius
Prodigy 30 points

Part Number: TMS320F28377D

I extended the .ebss section.

.cmd-file before afterwards 
   /* Allocate uninitalized data sections: */
   .stack              : > RAMM1        PAGE = 1
   .ebss               : >> RAMLS2_5 | RAMD0    PAGE = 1
   .bss                : >RAMGS15 PAGE = 1
   .esysmem            : > RAMD1       PAGE = 1
   .cio                : > RAMD0 PAGE = 1
 
   /* Allocate uninitalized data sections: */
   .stack              : > RAMM1        PAGE = 1
   .ebss               : >> RAMLS2_5 | RAMD0 | RAMGS15   PAGE = 1
   .bss                : >RAMGS15 PAGE = 1
   .esysmem            : > RAMD1       PAGE = 1
   .cio                : > RAMD0 PAGE = 1

Additionally I allocated a large object in RAM.
As a side effect the function-pointer _lock is allocated in RAMGS15:

.map-file before afterwards 
  0000b76a    00000002     rts2800_fpu32.lib : _lock.obj (.ebss:__lock)
  0000b76c    00000002                       : _lock.obj (.ebss:__unlock)
 
  0001b8a8    00000002     rts2800_fpu32.lib : _lock.obj (.ebss:__lock)
  0001b8aa    00000002                       : _lock.obj (.ebss:__unlock)

With the changes I observe that _lock is not initialized with an address -- instead means it remains zero.
I analyzed the cinit procedure:
The cinit-entry for _lock exists and is executed, but the init-value is not written to the destination (_lock).

More background information about the problem
At the begin of a debug-session the programm does not halt at main.

I found out that the PC jumps to 0.
Because in minit() the function-ptr is called _lock but it is zero.

  • +1
    TI__Mastermind 32655 points

    Hi,

    Since GSRAM is shared between CPU1 and CPU2, you need to configure it's ownership to CPU1/CPU2. Only the owner core has write access to the GSRAMs.

    It is configured in GSxMSEL register in Memcfg module. Can you check this register and confirm that the configuration is correct?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Prodigy 30 points

    Hi Veena,
    I checked then GSxMSEL register and it is responsible for the effects. Thank you.

    The above description refers to CPU2. And the GSxMSEL register is correctly initialized by CPU1, but apparently too late:
    When CPU1 executes the initialization, CPU2 has already processed the cinit-list.

    You know a way to assign GS15 to CPU2 before cinit is processed?

  • +1 in reply to Tjarko Möbius
    TI__Mastermind 32655 points

    Hi,

    CPU2 boot is initiated by CPU1 using the function IPCBootCPU2 / Device_bootCPU2. You invoke this function  only after CPU1 completes all the common initialization.

    This is applicable for standalone execution. While using debugger ,this function is bypassed and the debugger itself boots the CPU2. In that case, you make sure you click "Run" in CPU2 only after CPU1 init is completed

    Regards,

    Veena