• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 83 subscribers
  • Views 665 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.

TMS320F28P550SJ: F28P55: variables' data become strange because of memory issue

Quentin Fu
Intellectual 790 points
Part Number: TMS320F28P550SJ
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Our project used to run fine. The project contains a few modules which are all logically correct, which is verified in some way. But one module, let me call it "Module1", seems to have caused some memory issue.

  1. If commenting out "Module1", the whole project runs fine.
  2. If including "Module1", when running the project, some variables become strange, such as "-Inf"  "NaN". "-Inf" means "minus infinite" and "NaN" means "not a number"? Below is the screen capture of the "Expression tab":

These variables are defined in "cla_shared" because they are used by both CPU and CLA

I believe it is a memory issue because "Module1" is logically correct. I guess there are 2 possibilities:

  1. stack overflow happened,  or
  2. dynamic memory allocation (heap) issue

I tried to increase stack and heap size but failed to resolve the problem.  Below is the .cmd file; could you advise how to fix it?

==========

MEMORY
{
   BEGIN            : origin = 0x080000, length = 0x000002  // Update the codestart location as needed

   BOOT_RSVD        : origin = 0x000002, length = 0x000126     /* Part of M0, BOOT rom will use this for stack */
   RAMM0            : origin = 0x000128, length = 0x0002D8
   RAMM1            : origin = 0x000400, length = 0x000400

   RAMLS0           : origin = 0x008000, length = 0x000800
   RAMLS1           : origin = 0x008800, length = 0x000800
   RAMLS2           : origin = 0x009000, length = 0x000800

   /* Quentin 20240307: Combining all the LS RAMs */
   //RAMLS012        : origin = 0x008000, length = 0x001800
   //RAMLS12        : origin = 0x008800, length = 0x001000


   RAMLS3           : origin = 0x009800, length = 0x000800



//   RAMLS4           : origin = 0x00A000, length = 0x000800
//   RAMLS5           : origin = 0x00A800, length = 0x000800
//   RAMLS6           : origin = 0x00B000, length = 0x000800
//   RAMLS7           : origin = 0x00B800, length = 0x000800

      /* Quentin 20240110: Combining all the LS RAMs */
   RAMLS4567        : origin = 0x00A000, length = 0x002000


   RAMLS8           : origin = 0x014000, length = 0x002000  // When configured as CLA program use the address 0x4000
   RAMLS9           : origin = 0x016000, length = 0x002000  // When configured as CLA program use the address 0x6000

   // RAMLS8_CLA    : origin = 0x004000, length = 0x002000  // Use only if configured as CLA program memory
   // RAMLS9_CLA    : origin = 0x006000, length = 0x002000  // Use only if configured as CLA program memory

   //RAMGS0           : origin = 0x00C000, length = 0x002000
   //RAMGS1           : origin = 0x00E000, length = 0x002000
   RAMGS01          : origin = 0x00C000, length = 0x004000

   RAMGS2           : origin = 0x010000, length = 0x002000
   RAMGS3           : origin = 0x012000, length = 0x002000

   /* Flash Banks (128 sectors each) */
   FLASH_BANK0     : origin = 0x080002, length = 0x1FFFE
   FLASH_BANK1     : origin = 0x0A0000, length = 0x20000
   FLASH_BANK2     : origin = 0x0C0000, length = 0x20000
   FLASH_BANK3     : origin = 0x0E0000, length = 0x20000
   FLASH_BANK4     : origin = 0x100000, length = 0x20000


   CLATOCPURAM      : origin = 0x001480,   length = 0x000080
   CPUTOCLARAM      : origin = 0x001500,   length = 0x000080
   CLATODMARAM      : origin = 0x001680,   length = 0x000080
   DMATOCLARAM      : origin = 0x001700,   length = 0x000080

   RESET            : origin = 0x3FFFC0, length = 0x000002
}


SECTIONS
{
   codestart        : > BEGIN
   .text            : >> FLASH_BANK0 | FLASH_BANK1, ALIGN(8)
   .cinit           : > FLASH_BANK0, ALIGN(8)
   .switch          : > FLASH_BANK0, ALIGN(8)
   .reset           : > RESET, TYPE = DSECT /* not used, */

   //.stack           : > RAMM1
   // Quentin 20240307: change .stack from RAMM1 to RAMLS0 for more space
   //.stack           : > RAMLS0
   // Quentin 20240424: change .stack from RAMLS0 to RAMGS0:  1. for more stack space  2. for RAMLS0 used for CLA
   //.stack           : > RAMGS0
   .stack           : > RAMGS01

#if defined(__TI_EABI__)
   //.bss             : > RAMLS5
   .bss             : > RAMLS4567

   //.bss:output      : > RAMLS3
   // Quentin 20240323: replace line above with line below, to leave RAMLS3 for other usage
   //.bss:output      : > RAMLS12
   // Quentin 20240323: since I am not sure about correct usage of RAMLS8 as CLA memory, replace line above with line below to change from using RAMLS12 to RAMLS8
   //.bss:output      : > RAMLS8
   // Quentin 20240525 : I am afraid putting .sysmem & .data together at RAMLS8 might cause problem, so replace RAMLS8 with RAMGS2
   .bss:output      : > RAMGS2


   .init_array      : > FLASH_BANK0, ALIGN(8)
   .const           : > FLASH_BANK0, ALIGN(8)

   //.data            : > RAMLS5  | RAMLS6
   //.data            : > RAMGS0
   // Quentin 20240307: to prevent stack overflow to GSRAM, replace line(RAMGS0) above with line below(RAMLS12):
   //.data            : > RAMLS12
   // Quentin 20240323: since I am not sure about correct usage of RAMLS8 as CLA memory, replace line above with line below to change from using RAMLS12 to RAMLS8
   //.data            : > RAMLS8
   .data            : > RAMLS9

   //.sysmem          : > RAMLS4
   //.sysmem          : > RAMGS0
   // Quentin 20240307: to prevent stack overflow to GSRAM, replace line(RAMGS0) above with line below(RAMLS12):
   //.sysmem          : > RAMLS12
   // Quentin 20240323: since I am not sure about correct usage of RAMLS8 as CLA memory, replace line above with line below to change from using RAMLS12 to RAMLS8
   //.sysmem          : > RAMLS8
   // Quentin 20240525 : I am afraid putting .sysmem & .data together at RAMLS8 might cause problem, so replace RAMLS8 with RAMGS3
   .sysmem          : > RAMGS3

#else
   .pinit           : > FLASH_BANK0, ALIGN(8)
   //.ebss            : >> RAMLS5 | RAMLS6
   .ebss            : >> RAMLS4567

   .econst          : > FLASH_BANK0, ALIGN(8)
   //.esysmem         : > RAMLS5
   .esysmem         : > RAMLS4567

#endif

   //ramgs0 : > RAMGS0
   //ramgs1 : > RAMGS1
   ramgs2 : > RAMGS2









   #if defined(__TI_EABI__)
       .TI.ramfunc : {} LOAD = FLASH_BANK0,

                        //RUN = RAMLS0,
                        RUN = RAMLS4567,

                        LOAD_START(RamfuncsLoadStart),
                        LOAD_SIZE(RamfuncsLoadSize),
                        LOAD_END(RamfuncsLoadEnd),
                        RUN_START(RamfuncsRunStart),
                        RUN_SIZE(RamfuncsRunSize),
                        RUN_END(RamfuncsRunEnd),
                        ALIGN(8)
   #else
       .TI.ramfunc : {} LOAD = FLASH_BANK0,

                        //RUN = RAMLS0,
                        RUN = RAMLS4567,

                        LOAD_START(_RamfuncsLoadStart),
                        LOAD_SIZE(_RamfuncsLoadSize),
                        LOAD_END(_RamfuncsLoadEnd),
                        RUN_START(_RamfuncsRunStart),
                        RUN_SIZE(_RamfuncsRunSize),
                        RUN_END(_RamfuncsRunEnd),
                        ALIGN(8)
   #endif









/* CLA specific sections */

#if defined(__TI_EABI__)
    /* CLA specific sections */
    Cla1Prog        : LOAD = FLASH_BANK0,
                      RUN = RAMLS0,
                      LOAD_START(Cla1ProgLoadStart),
                      RUN_START(Cla1ProgRunStart),
                      LOAD_SIZE(Cla1ProgLoadSize),
                      ALIGN(4)
#else
    /* CLA specific sections */
    Cla1Prog        : LOAD = FLASH_BANK0,
                      RUN = RAMLS0,
                      LOAD_START(_Cla1ProgLoadStart),
                      RUN_START(_Cla1ProgRunStart),
                      LOAD_SIZE(_Cla1ProgLoadSize),
                      ALIGN(4)
#endif





// below is from  F28P55 cla_ex4_pwm_control example project  (20240419)
   Cla1ToCpuMsgRAM  : > CLATOCPURAM
   CpuToCla1MsgRAM  : > CPUTOCLARAM

   .scratchpad      : > RAMLS1
   .bss_cla         : > RAMLS1

   Cla1DataRam      : > RAMLS2
   cla_shared       : > RAMLS1
   CLADataLS1       : > RAMLS1







#if defined(__TI_EABI__)
   .const_cla      : LOAD = FLASH_BANK0,
                      RUN = RAMLS1,
                      RUN_START(Cla1ConstRunStart),
                      LOAD_START(Cla1ConstLoadStart),
                      LOAD_SIZE(Cla1ConstLoadSize),
                      ALIGN(4)
#else
   .const_cla      : LOAD = FLASH_BANK0,
                      RUN = RAMLS1,
                      RUN_START(_Cla1ConstRunStart),
                      LOAD_START(_Cla1ConstLoadStart),
                      LOAD_SIZE(_Cla1ConstLoadSize),
                      ALIGN(4)
#endif



}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

CLA shared memory

  • 0
    TI__Mastermind 32565 points

    Can you please share a code snippet how those variables are computed?

    Are you using heap memory?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 790 points

    Hi Veena,

    Below are some code snippets:  C_DS3 = comp3_DS3 * P_power_fil_DS3 * 0.0011 + comp5_DS3;

    but I guess this issue has nothing to do with how the variables are computed, and the variable's data become strange only because some memory issue happened, such as stack overflow, heap issue, etc

    Yes, both stack and heap memory are used. Please advise how to fix.

    Thanks,

    Quentin

  • 0 in reply to Quentin Fu
    TI__Mastermind 32565 points

    Is this computation on C28 core or CLA code? If it is on CLA, please confirm if these variables and others which are used for computation is placed in a CLA accessible memory?

    Are these variables declared statically or dynamically? Math functions from the compiler library only uses stack, and not heap.

    You get Nan when you try 0/0 or while using initialized variables or some other illegal math operations. Could you confirm this?. Were you able to identify the exact operation that caused the Nan or Inf error?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 790 points

    Please see below:

    1. This specific computation  C_DS3 = comp3_DS3 * P_power_fil_DS3 * 0.0011 + comp5_DS3  is on c28core.  Some variables are placed in CLA accessible memory when needed -- I have been using these for quite a few years and am very familiar with them.

    2. These are global variables declared statically 

    3. I don't think there are illegal math operations. As mentioned in my first post, if commenting out "Module1" which is logically correct and HAS NOTHING TO DO WITH THESE VARIABLES, the whole project runs fine and all these variable's data are correct

  • 0 in reply to Quentin Fu
    TI__Mastermind 32565 points

    If you are suspecting it is a stack overflow issue, can you try one of the stack overflow detection techniques (using ERAD or memory fill method etc). But I am not sure since you mentioned increasing the stack size did not help.

    Other thing you could check is - Is the C28-CLA shared data placed in a LSRAM or MSGRAM? If it is LSRAM, both cores have write access and you may need some synch mechanism to ensure both are not trying to write to the same location at the same time.

    Also, when "Module1" is integrated into the project, is there a difference in the memory allocation of these variables? Is it crossing LSRAM block boundary?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 790 points

    Hi Veena,

    Could you elaborate on (using ERAD or memory fill method etc)? I am not familiar with them.

    Thanks,

    Quentin

  • 0 in reply to Quentin Fu
    TI__Mastermind 32565 points

    Using the ERAD module, you can monitor the memory accesses. We have an example on stack overflow which checks if there is any access to the memory region towards the end of the allocated stack memory.

    Memory fill technique is basically filling the entire stack memory with some known pattern, run the application for some duration, and check if the contents are updated towards the end of the stack.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Intellectual 790 points

    The .cmd file was provided earlier. Here is a short summary:

    • Global variable  Relay_phi_a_U_flag , as initialized global variable, is placed in  RAMLS9
    • Global variable  comp5_DS3, as shared variable between CPU & CLA,  is placed in  RAMLS1


    Below are copied from .cmd:

    ===========
            .data            : > RAMLS9   \\ initialized

            .scratchpad      : > RAMLS1
            .bss_cla         : > RAMLS1

            cla_shared       : > RAMLS1
            CLADataLS1       : > RAMLS1

            RAMLS1           : origin = 0x008800, length = 0x000800
            RAMLS9           : origin = 0x016000, length = 0x002000  // When configured as CLA program use the address 0x6000
    ===========


    Below are copied from .map:

    ===========
    000160a0     582 (00016080)     Relay_phi_a_U_flag
    0     00008814  comp5_DS3

    ===========

    • "Module1” is logically correct and HAS NOTHING TO DO WITH THE VARIABLES  Relay_phi_a_U_flag & comp5_DS3.
    • If "Module1” is NOT integrated, everything runs fine and all the variables’ data are correct
    • If "Module1” is  integrated, data of Relay_phi_a_U_flag & comp5_DS3 become weird. It seems some memory issue, such as stack overflow, or heap memory issue, or something else happened, and causes RAMLS1 & RAMLS9 are “invaded” or “corrupted” somehow, and hence the variables in RAMLS1 & RAMLS9 become weird.

      Please advise how to resolve the issue. Thanks.
  • 0 in reply to Quentin Fu
    Intellectual 790 points

    It seems some memory issue, such as stack overflow, or heap memory issue, or something else happened, and causes RAMLS1 & RAMLS9 are “invaded” or “corrupted” somehow, and hence the variables in RAMLS1 & RAMLS9 become weird.

     .cmd is provided; summary of .cmd and the issue is also provided; please advise how to update .cmd to resolve the issue.

    Thanks,

    Quentin

  • 0 in reply to Veena Kamath
    Intellectual 790 points

    Hi Veena,

    It seems some memory issue, such as stack overflow, or heap memory issue, or something else happened, and causes RAMLS1 & RAMLS9 are “invaded” or “corrupted” somehow, and hence the variables in RAMLS1 & RAMLS9 become weird.

     .cmd is provided; summary of .cmd and the issue is also provided; please advise how to update .cmd to resolve the issue.

    Thanks,

    Quentin

  • 0 in reply to Veena Kamath
    TI__Expert 4305 points

    Hi Veena,

    This issue of has been stuck here for a long time, can you help take a look for customer? We now suspect that this is a memory issue, and would like to confirm with you that, if a stack overflow occurs, will the overflowed part affect the values of other memory addresses?

    And here are some additional notes on this issue:


    1. Customer's code runs fine on other C2000 series (), and the customer does not think there is any logical error, but when it is ported to F28P55x it will have this issue.

    2. Not only the values of the above three variables will have issue, but many variables have this kind of issue.

    3. Customer have expanded the address of the stack to very large and still have this issue.

    4. Customer said that adding a "Module1" would make the value of the variable strange, and customer checked that "Module1" have no code that will modify the issue variable.

    5. This issue can be reproduced on multiple boards

    Thanks,

    Julia

  • 0 in reply to Julia Li
    Intellectual 790 points

    Thank Julia for the notes and summary.

    Yes, this same project runs fine on 280025.

    I believe this is a memory issue. When it happens,  RAMLS1 & RAMLS9 are “invaded” or “corrupted” somehow, and hence the variables in RAMLS1 & RAMLS9 become weird.

  • 0 in reply to Quentin Fu
    TI__Mastermind 32565 points

    Hi,

    Please note that LS8 and 9 are different than other LSRAMs.

    These when used as CLA memory, can only be configured as program memory. It cannot be used as CLA data memory. Can you confirm this is the case.

    Also the address of these RAMs are different when accessed from C28 and C29. Hence C28 code that copies the CLA code from Flash to RAM, is different. We do have an example in C2000ware demonstrating this -> cla_asin_ls8_9

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    TI__Mastermind 32565 points

    Hi,

    Please note that LS8 and 9 are different than other LSRAMs.

    These when used as CLA memory, can only be configured as program memory. It cannot be used as CLA data memory (CLA cannot make data accesses to this block). Can you confirm this is the case.

    Also the address of these RAMs are different when accessed from C28 and C29. Hence C28 code that copies the CLA code from Flash to RAM, is different. We do have an example in C2000ware demonstrating this -> cla_asin_ls8_9

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    TI__Mastermind 32565 points

    Snapshot from the device data sheet

  • 0 in reply to Veena Kamath
    Intellectual 790 points

    Hi Veena:

     

    It can be seen from .cmd provided earlier that RAMLS8 & 9 are NOT used as CLA memory – RAMLS0 is used as CLA PROGRAM RAM, and RAMLS1 & 2 are used as CLA DATA RAM.

    Quentin