MPC-5125 Linker Command File Guidance

[Tim562]

Hi All,

I need to locate all the uninitialized data variables from a *.c module to MRAM that I have available on the processor LocalPlus Bus. I'm having a difficult time finding documentation for customizing the Linker Command File for an MPC-5125 project using the Classic CodeWarrior for MobileGT V9.2.

I'm guessing that I need to add an entry to the MEMORY section of my project.lcf file like this (added MYMRAM to existing MEMORY contents):

MEMORY      {      SDRAM:  org = 0x00000000, len = 0x10000000      // 256MB DDR SDRAM  = 0x0000_0000 to 0x0FFF_FFFF      MYMRAM: org = 0x10000000, len = 0x00100000      // 1MB MRAM = 0x1000_0000 to 0x100F_FFFF on Processor LocalPlus Bus      SRAM:   org = 0x30000000, len = 0x00008000      // 32K Internal SRAM = 0x3000_0000 to 0x3000_7FFF      IMMR:   org = 0x80000000, len = 0x00100000      // 1MB     = 0x8000_0000 to 0x800F_FFFF      FLASH:  org = 0xFFF00000, len = 0x00800000      // 8MB FLASH   = 0xFFF0_0000 to 0x1_006F_FFFF      }    

Then add an entry to the SECTIONS section of my project.lcf file like this:

SECTIONS      { /* Existing Group definitions for .code, etc. here */       GROUP : {                    /* Add this entry */            .mymram_data : {}           } > MYMRAM       GROUP : {            .rosdata : {}           .sdata : {}           .sbss : {}           } > ram    GROUP : {           .rosdata2 : {}           .sdata2 : {}           .sbss2 : {}           } > ram      GROUP : {           .data : {}           .bss : {}           .image (DATA) :                {                __START_IMAGE_DATA =.;                * (.image_data)                  }           } > ram      }     

Finally I think I need to add a pragma to my vars.c module to put all variables in the myMram section:

#pragma push              //Store pragma context  #pragma section  data_type sdata_type ".mymram_data"  ".mymram_data" //switch to the myMram_data section to store data  unsigned char SourceAlphas[gcMAXINCHANS][gcALPHALENGTH];  unsigned char DestAlphas[gcMAXOUTCHANS][gcALPHALENGTH];  unsigned char OptoAlphas[gcMAXOPTOS][gcALPHALENGTH];  unsigned char RelayAlphas[gcMAXRELAYS][gcALPHALENGTH];  #pragma pop           //Restore pragma context    

When I compile I get the following compiler warning: "No linker command file input for section '.mymram_data' in file ...\project\vars.o. Output section '.mymram_data' will be created". When I look in the "extram_d.MAP file I see a section layout for ".mymram_data" with no data variables in it. I am wondering if I'm even close to a correct solution or way off base? Any documentation for locating a modules RAM variables in a specific address window using the MPC-5125? Maybe I'm close with all this and just need a little tweak? Thanks in advance to any who can help.

Best Regards,

Tim Hutchinson

P.S.

I've also read that the section pragma is depreciated and instead I should use __declspec() like this? If this is right, how to do all vars in an entire module with this?

__declspec(section ".mymram_data") unsigned char SourceAlphas[gcMAXINCHANS][gcALPHALENGTH];    

[Tim562]

Hi All,

     Thought I'd share the final resolution of this problem in this forum. It turns out that using the Classic CodeWarrior for MobileGT V9.2 it is not possible to create an address memory segment that will store uninitialized data (per Freescale tech support). Any data segments created in the *.lcf file other then the .bss segment are considered to contain initialized data objects. Now, it is possible to set the location of the .bss segment to any memory window but that means that all uninitialized data objects will be placed in that segment (not practical in my situation).

     In my case, I have a small amount of non-volatile ram that is available on the LocalPlus bus of the Freescale MPC-5125 and I wanted to store some of my project data objects in it so the data values would be retained over power cycle events. Can't do it. What I've done as a workaround is to access my data objects using pointers that are able to access the memory window where my non-volatile ram exists. Kind of a pain, but workable. Hope this helps!

Best Regards,

Tim

[stanish · Accepted solution]

Hello Tim,

I've just tested it on my CW for MGT v9.2 and I can place an initialized and uninitialized data into the separate custom sections:

my.lcf:

MEMORY {

...

  MYMRAM: org = 0x10000000, len = 0x00100000  

...

}

SECTIONS {

...

     GROUP : {                    /* Add this entry */ 

           .mymram_bss(BSS) : {} 

           .mymram_data(DATA) : {} 

          } > MYMRAM

...

main.c:

#pragma push              //Store pragma context 

#pragma section data_type sdata_type ".mymram_data"  ".mymram_bss"

unsigned char GotoBSS[5][5];

unsigned char GotoDATA[5][5]={{1,1},{2,2}};

#pragma pop

void main()

{

  unsigned char i=0;

  GotoBSS[0][0] = i;

  GotoDATA[0][0] = i;

while(1) { i++}

}

.MAP file

.mymram_data section layout

  Starting        Virtual  File

  address  Size   address  offset

  ---------------------------------

  00000000 000019 000074c8 000053a8  1 .mymram_data main.o

  00000000 000019 000074c8 000053a8  4 GotoDATA main.o

.mymram_bss section layout

  Starting        Virtual  File

  address  Size   address  offset

  ---------------------------------

  00000000 000019 000074e4 000053c4  1 .mymram_bss main.o

  00000000 000019 000074e4 000053c4  4 GotoBSS main.o

so seems the build tools allow you to add uninitialized data into a custom bss section.

Can you possibly try this easy example on your side?

Stan

[Tim562]

Hi Stan,

     I apologize for taking so long to respond to your post. I had moved on to continue development of this product using the pointer solution I describe above and wasn't aware that anyone had responded here! Thanks very much for taking the time to work this problem out. I tried the code you supplied and it did indeed cause CodeWarrior to allocate the required memory areas at the proper address locations and the variables were located in the proper memory segments. All this worked properly! However.... (there's always a however isn't there : )...

     When the CodeWarrior Debugger tried to load the application for debugging, it crashed almost immediately. I set the debugger to "Stop On Application Launch" and stepped through the MQX init process to see what was blowing up. The MQX function __start() is the first function called, it calls __init_data(void). The data init process crashes while attempting to initialize data to zero.

     Pretty sure this is because MQX is trying to initialize the "mymram" data section before my code has initialized the LocalPlus Bus. Even if I modify your example to not include the GotoDATA[5][5] = {{1,1}, {2,2}}; (initialized data) array, MQX still attempts an initialization. I suspect that if I modified the MQX code to setup the LocalPlus Bus as I require it before doing the data init or if I modified MQX to not init the address windows that are located in my MRAM section, I could get this to work. I'm not sure either of those ideas is practical. Do you have any ideas on how I might allow MQX to wake up when it can't access some memory windows for initialization until my code gets the LocalPlus Bus working? I would really prefer to not have to use pointers to access all my data objects stored in mram and do things as you've outlined in your post.

Thanks again for your attention to this.

Best Regards,

Tim Hutchinson

[Tim562]

Still unable to properly locate un-initialized data objects at a specific location in the address space. Anybody have any comments on how you've done this? Suggestions?

~Tim

[stanish]

Hello Tim,

Could you perhaps try to split pragma section into initialzed and unitialized section:

   GROUP : {     

     .mymram_bss  (BSS) :{}

     .mymram_data (DATA) :{}

   } > my_bss

...

#pragma push              //Store pragma context  

#pragma section data_type sdata_type ".mymram_data"  ".mymram_bss"

unsigned char GotoBSS[5][5];

unsigned char GotoDATA[5][5]={{1,1},{2,2}};

#pragma pop

These variables needs to be referenced in your code otherwise they will be removed by the build tools.

Can you please paste the Memory Map from generated .map file?

Stan

[Tim562]

Project lockup problem resolved. Was happening when my test code attempted to read from the MRAM on the LocalPlus Bus before I had configured the LocalPlus Bus!

Still not sure why data arrays placed in the MYMRAM section appear as "initialized data" and the size of any data objects are added to the size of the code download for a debugging session. At this point can only place a very small amount of data in this section else the debugger exits with the memory error I spec'd above. Any ideas?

~Tim

[Tim562]

I'm wondering if I'm even close to being on the correct track with this. Besides the fact that the size of any data objects declared in my new MYMRAM section are added to the code download for a CodeWarrior debugging session, most times, if I actually refer to one of those variables in my code (so the linker includes it in it's output file) my project freezes and won't run properly. If I comment out the single code line that reads from a variable in that section, all works fine again.

Has anybody tried to locate data variables at specific memory addresses in their projects? How did you do it?

Thanks!

Tim

[Tim562]

Hi All,

     I've gotten this to compile and to locate my variables in the specified address window (by placing my new MYMRAM group at the end of the existing SECTIONS > ram entries) but now it seems that any data items placed in this custom address window are added to the size of the code download that the CodeWarrior USB TAP makes to the target when starting a debug target. When I attempt to start a debug session the code starts downloading then I get a "CCSProtocolPlugin : Error writing memory [SAP : write over-flow]" error. The size of the download changes as I change the size of data vars placed in this section. Why? This is data not code right? I'm guessing I'm not declaring something properly in the SECTIONS area and the compiler thinks that variables placed in this new area are constants? If I only place a small byte array (256 bytes for example) in this section, all seems to work properly and I can read/write it just as I would expect.

On a related topic, does anybody know why I would be getting the above described memory error when trying to download/debug a project that's grown to around 2.8 MB? Once I remove the data objects from my custom section the USB TAP download returns to around 1.8 MB and all works properly but does that mean there is some limit to my project code size that has nothing to do with the resources available on my target? I'm using the Freescale TWR-MPC-5125 tower module which has 256MB or DRAM and gigabytes of flash so I should be a long ways from running out of resources. Right? Any ideas, observations or comments welcomed.

Thanks,

Tim