TMS320F28069: Problems of modifying cmd file

Thanks for reaching out to the TI E2E forums.

I found a small error in the .cmd you attached above, at line 138/139 you've allocated both DMARAML5 and DMARAML6 to the same physical memory space. Since L5 is now allocated to your .ebss/.econst we definitely don't want the DMARAML5 mapped there, I'd just delete that line of code or you could break RAML6 into smaller chunks if you need separate allocations for the DMA.

   DMARAML5	        : > RAML6,      PAGE = 1
   DMARAML6	        : > RAML6,      PAGE = 1

In terms of functionality for code or data, all the Lx RAMs are identical in performance.  The DPSRAM is Dual Port, since they are shared between the CPU and either the CLA(L0-L3) or the DMA(L5-L8).  If you are not using either, then there will be no performance penalty to your C28x data or program.  There is a init process for the CLA, so I don't believe you've accidentally activated it.  If you are using the DMA, we may want to check

Finally, even though we've allocated specific RAMs for the DMA, the DMA itself is not automatically blocked from any address it has access to.  So even though L5 is not allocated to DMA in the linker, if you've programmed it to write to those address in L5 there's nothing that could stop it from doing do.  Esp if you were using L5 previously for the DMA I'd have a look at the DMA initialization code to make sure its not still pointing to L5 either in an active or a shadow register load/reload.

Let me know what you find and if I can be of more help.

Best,

Matthew

MatthewPate said:

  Esp

Thank you for your timely reply. I have deleted the line for the allocation of DMARAML5 as you mentioned. But the problem is still the same. Now my cmd file looks like as below

MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */

   BEGIN       : origin = 0x000000, length = 0x000002
   RAMM0       : origin = 0x000050, length = 0x0003B0
   RAML0_L3    : origin = 0x008000, length = 0x004000	 /* RAML0-3 combined for size of .text */
   														 /* in Example_F2806xSWPrioritezedInterrupts */
   RESET       : origin = 0x3FFFC0, length = 0x000002
   FPUTABLES   : origin = 0x3FD860, length = 0x0006A0	 /* FPU Tables in Boot ROM */
   IQTABLES    : origin = 0x3FDF00, length = 0x000B50    /* IQ Math Tables in Boot ROM */
   IQTABLES2   : origin = 0x3FEA50, length = 0x00008C    /* IQ Math Tables in Boot ROM */
   IQTABLES3   : origin = 0x3FEADC, length = 0x0000AA	 /* IQ Math Tables in Boot ROM */

   BOOTROM    : origin = 0x3FF3B0, length = 0x000C10


PAGE 1 :

   BOOT_RSVD   : origin = 0x000002, length = 0x00004E     /* Part of M0, BOOT rom will use this for stack */
   RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
   RAML5       : origin = 0x00C000, length = 0x002000     /* on-chip RAM block L5 */
   RAML6       : origin = 0x00E000, length = 0x002000     /* on-chip RAM block L6 */
   RAML7       : origin = 0x010000, length = 0x002000     /* on-chip RAM block L7 */
   RAML8       : origin = 0x012000, length = 0x002000     /* on-chip RAM block L8 */
   USB_RAM     : origin = 0x040000, length = 0x000800     /* USB RAM		  */
}


SECTIONS
{
   /* Setup for "boot to SARAM" mode:
      The codestart section (found in DSP28_CodeStartBranch.asm)
      re-directs execution to the start of user code.  */
   codestart        : > BEGIN,      PAGE = 0

   ramfuncs         : > RAMM0,      PAGE = 0
   .text            : > RAML0_L3,   PAGE = 0
   .cinit           : > RAMM0,      PAGE = 0
   .pinit           : > RAMM0,      PAGE = 0
   .switch          : > RAMM0,      PAGE = 0
   .reset           : > RESET,      PAGE = 0, TYPE = DSECT /* not used, */

   .stack           : > RAMM1,      PAGE = 1
   .ebss            : > RAML5,      PAGE = 1
   .econst          : > RAML5,      PAGE = 1
   .esysmem         : > RAML5,      PAGE = 1

   IQmath           : > RAML0_L3,   PAGE = 0
   IQmathTables     : > IQTABLES,   PAGE = 0, TYPE = NOLOAD

   /* Allocate FPU math areas: */
   FPUmathTables    : > FPUTABLES,  PAGE = 0, TYPE = NOLOAD

   DMARAML6	        : > RAML6,      PAGE = 1
   DMARAML7	        : > RAML7,      PAGE = 1
   DMARAML8	        : > RAML8,      PAGE = 1

}

Besides, I am not using DMA in my project. Maybe I have initialized the clock for DMA, but absolutely I did not write any code for DMA.

Addition clues have been found. After I ran my code, all of the variables just changes randomly and when pause it, it shows "Break at address "0x89" with no debug information available, or outside of program code." as follows. I think the code has already gone out of control.

When I switch to the default cmd for flash mode, the code works fine, which proves that there is no mistake about my code.

In a word, the cmd for RAM is still not working, can you give me addtional help?

I have found new clues.

I tried to run my code line by line and found that whenever the program ran into the third line of this function below, it would crash.

void send_data(char screen,const char control_id[2],float freq,char* format){
    char *result;

    result = malloc(40);
    sprintf(result,format,freq);

    scia_send_char(send_begin, 3);
    if(screen == 0){
        scia_send_char(screen_id0, 2);
    }else{
        scia_send_char(screen_id1, 2);
    }
    scia_send_char((char *)control_id, 2);
    scia_msg(result);
    scia_xmit('\0');
    scia_send_char(send_end, 4);
    free(result);
}

I guess maybe it is the problem for the variable "result". I checked the address of it and found that it is inside ".stack" area, which is mapped to M1 SARAM.

   .stack           : > RAMM1,      PAGE = 1

I tried to re-map .stack to another place, which is L6 and then it works, the code works perfectly.

Though I have solved this, I am totally confused and I still don't know why. Looking forward to your replay!

Glad that you are able to continue to debug/develop the code.  Are you copying any sections from Flash to RAM to speed up the execution?  You would see the memcpy() function in your code. 

Looking at the linker, there is nothing intentional being allocated to M1 other than the stack.  I will add the M0/M1 are contiguous, so if M0 were larger than we thought it could over-write M1.  The linker should have thrown an error if M0 sections were in excess of what you have allocated, unless the pinit or cinit is dynamic.

If you look in the debug directory there should be a .map file generated, if you could look through this with the old linker it would show if there is some of M1 space somehow allocated. 

Right now I'm thinking the memcpy is the most obvious reason.

Best,

Matthew

Hi, MathewPate, thank you for your reply.

Actually, I did not use memcpy() to copy any sections from FLASH to RAM. However, inspired by your suggestion, I tried to see the address of result, which is allocated dynamically in the function below. When the old linker is adopted, I found that the address for result is allocated to "0x00000408", which is inside M1 section.

void send_data(char screen,const char control_id[2],float freq,char* format){
    char *result;

    result = malloc(40);
    sprintf(result,format,freq);

    scia_send_char(send_begin, 3);
    if(screen == 0){
        scia_send_char(screen_id0, 2);
    }else{
        scia_send_char(screen_id1, 2);
    }
    scia_send_char((char *)control_id, 2);
    scia_msg(result);
    scia_xmit('\0');
    scia_send_char(send_end, 4);
    free(result);
}

Since 0x00000408 is inside ".stack", I think maybe there is something wrong because as far as I know, dynamically allocated memory should be in heap. So is it due to this that causes the code to crash?

According to the information in "SPRU514", which is the compiler user's guide, the dynamically allocated memory should be inside ".sysmem" section. However, ".sysmem" is not defined in my linker, so, should I try to define ".sysmem" to a certain place to solve this problem?

Yu Qi1 said:

According to the information in "SPRU514", which is the compiler user's guide, the dynamically allocated memory should be inside ".sysmem" section

The ".sysmem" section in used for EABI, and ".esysmem" is used for COFF.

In the CCS project properties under CCS General -> Project is Output Format is set to "legacy COFF" or "eabi (ELF)"?

Some of the C2000 example linker command files only have the sections for COFF, and if the project is changed to be EABI the EABI section names need to be added to the linker command file. E.g. If you get warnings such as the following:

warning #10440-D: creating output section ".sysmem" without a SECTIONS specification. For additional information on this section, please see the 'C2000 Migration from COFF to EABI' guide at https://software-dl.ti.com/ccs/esd/documents/C2000_c28x_migration_from_coff_to_eabi.html

Hi,Gillon. Thanks for answering. Currently, the output format is legacy COFF.
But about the problem I faced, do you have any idea?
thank you