Linker Command File (LCF) P:RAM Clarification

[Derrick]

Hello,

I have been helping a customer get a better understanding of how to configure their LCF for our MC56F8037 using CodeWarrior 10.7.  The reference material that we have been using include:

  - 56800/E Digital Signal Controllers: MC56F8xxx/DSP5685x Targeting Manual

  - AN5143 "Relocate Subroutines to PRAM for MC56F827xx DSC"

The examples provided in this documentation do not seem to clearly explain how to describe the P:RAM in the LCF.  The customer needs to execute subroutines in P:RAM.

According to the 56F8037/56F8027 Data Sheet,

  - P:$00_0000 to P:$00_7FFF  = Program Flash

  - P:$00_8000 to P:$00_8FFF  = Program RAM

  - X:$00_0000 to X:$00_0FFF  = Data RAM

But the automatically generated linker command file produces the following:

 .p_interrupts_ROM     (RX)  : ORIGIN = 0x0000,   LENGTH = 0x0080   # reserved for interrupts
 .p_flash_ROM          (RX)  : ORIGIN = 0x0080,   LENGTH = 0x7F80  

 .p_flash_ROM_data     (RX)  : ORIGIN = 0x0000,   LENGTH = 0x0FFF   # internal xRAM mirror
                                                                    # for pROM-to-xRAM copy

 .x_internal_RAM       (RW)  : ORIGIN = 0x0000,   LENGTH = 0x0FFF  

Why is ".p_flash_ROM_data" not set to "ORIGIN = 0x8000"?

Why is there no ".p_RAM" space defined?

What would be the correct way to configure the linker command file so that the customer's subroutines can be relocated into Program RAM for the MCF8037 - as described in AN5143 for the MC56F827xx?  How does the "pROM-to-pRAM copy utility" work (which is briefly mentioned in AN5143)?

Best Regards,

Derrick

[xiangjun_rong]

Hi, Derrick,

As you know that MC56F8037 has on-chip flash and RAM, the MC56F8037 has two space, one is Program space with P: 0xxxxx address, another is data space with X:0xxxxx address. The MC56F8037 has 32KW(32Kx16 bits) flash and 4KW RAM, but the same 4KW RAM can be mapped to both program space and data space.

P: $00 8FFF to P: $00 8000   //4KW program RAM

X:$00 0FFF to  X:$00 0000    //4KW data RAM,

They are the same physical RAM.

Because there is only one block program flash, so the program flash has to be used to save both code and constant data. Furthermore, in application code, if you want to save data to program flash, you have to copy the flash programing code into program RAM and execute the flash programming code in Program RAM.

All the global variable and stack are located in data RAM, and if you want to save programming code to data program RAM, even copy the constant to data RAM, you have to allocate the data RAM carefully.

Regarding your question of p_flash_ROM_data, this is X space address instead of program space address. As the following lines in *.cmd file, the section is saved in program flash with the start address AT(__pROM_data_start), some constant data need to mirror to data RAM space, so it pre-allocate some memory size in the data RAM with the address p_flash_ROM_data. Application code has to copy from program flash to data RAM.

Hope it can help you

BR

Xiangjun rong

.data_in_p_flash_ROM : AT(__pROM_data_start)
        {
              # the data sections flashed to pROM
              # save data start so we can copy data later to xRAM

              __xRAM_data_start = .;

              # .data sections
              * (.const.data.char)  # used if "Emit Separate Char Data Section" enabled
              * (.const.data)

              * (fp_state.data)
              * (rtlib.data)
              * (.data.char)        # used if "Emit Separate Char Data Section" enabled
              * (.data)
        
        
        

              # save data end and calculate data block size
              . = ALIGN(2);
              __xRAM_data_end = .;
              __data_size = __xRAM_data_end - __xRAM_data_start;

        } > .p_flash_ROM_data    # this section is designated as p-memory
                                 # with X flag in the memory map
                                 # the start address and length map to
                                 # actual internal xRAM

[Derrick]

Hi Xiangjun rong,

While this would appear to work for data, it is not apparent how this will operate for subroutines.  How are the function calling addresses tracked?

Can you please provide a more detailed description for how this applies for subroutines that are copied into RAM?

Best Regards,

Derrick

[xiangjun_rong]

Hi, Derrick,

As you know that the you have to copy the eraseing/programming code to PRAM and execute the code in RAM if you want to erase/program flash.

I attach the project to erase/prpograme flash based on MC56F8037 based on PE, pls refer to it, especially IFsh1.c.

Hope it can help you

BR

Xiangjun rong

[j___]

Hi XR,

Thanks for the info. I have some questions about the demo that you sent.

Files attached:

  ---  A text file with the memory map for the 56F8013.

  ---  S-record generated by the demo project you provided

1) Why does .p_flash_ROM_data start at address 0x0001 (ORIGIN) instead of 0x0000 and end at address 0x7FF instead of 0x0800? This memory is "Unified RAM" so I would expect the ORIGIN address and length of the "p_flash_ROM_data" segment to be formatted the same as the "p_internal_RAM" segment. Unless, there is a specific reason to deduct "one" from each end. I thought that maybe it was due to Word access rather than Byte access. However, that would make sense for 0x7FF but NOT for 0x0001.

     .p_flash_ROM_data  (RX) : ORIGIN = 0x00000001, LENGTH = 0x000007FF

     #Other memory segments
     .p_internal_RAM  (RWX) : ORIGIN = 0x00008000, LENGTH = 0x0800

2) Why is "p_flash_ROM_data" designated as (RX) but yet it starts at 0x0001? The memory map states that executable RAM space starts at 0x8000. Yes!, they are the same memory, "Unified and overlapping". BUT, the memory map states that it should be 0x8000 for (X)=executable. In fact the LCF has an entry for (RWX) at 0x8000.

This is a really confusing sticking point. Can you consult with the DSC compiler group for a definitive answer to this?

3) I enabled S-record generation in the demo project that you provided and compiled it in CW8.3. The demo generates entries in the S-record starting at 0x00008000. How can I suppress these RAM-based entries? I am downloading this to flash using a "custom" boot-loader. The app must then be responsible for copying out the data to RAM. So, I want the "Ram Functions Image" in flash. I want the linker to "know" that the final destination is RAM. But, I do not want any RAM entries put into the S-record.

4) Looking at the demo project you provided, the flash programming function is literally written twice, once for flash once for RAM.

static asm void Run_and_wait_in_prog_flash(dword address, word data, word command)

static asm void Run_and_wait_in_RAM(dword address, word data, word command)

This seems very odd?!?!?!

The linker should be able to manage this without duplicating the code.

Why maintain code in two places?

Perhaps the explanation of this will be part of eliminating the unwanted S-record entries in question 3 ?!?

Regards,

J

[xiangjun_rong]

Hi, Jim,

For you first question that ".p_flash_ROM_data start at address 0x0001 (ORIGIN) instead of 0x0000 and end at address 0x7FF instead of 0x0800", I do not know the reason why one words 0x0000 is left. But I think the issue is not related to flash operation, I have created a new project with PE based on MC56F8323, the .p_flash_ROM_data always starts at address 0x0001 (ORIGIN) no matter whether you use flash bean or not, in other words, 0x0001 is a default setting.

For your second question, it is the same as first one.

For your third question, As you know that S recorder can only write flash, it is your application which is responsoible for copying your application code from flash to RAM. If you do want to creat an image which have to be copied from flash to RAM, I think you can define a binary array, have the compiler generate binary code(machine code) based on the function you want to copy from flash to RAM, and copy the binary code to the array. You can save the binary array in the flash, and get the start/end address of the array and save in the flash.

For your last question, I think it is okay. Of course, you have the other solution to access the api function in RAM which is copied from flash, for example, you can define a function point and have it point the RAM address.

Hope it can help you

BR

Xiangjun rong

[j___]

1) Not sufficiently answered.

Can you please put me in contact with someone from the DSC compiler group that can answer this?

2) Not sufficiently answered. I put in bold font that this was an important issue for me to understand the LCF.

Can you please put me in contact with someone from the DSC compiler group that can answer this?

3) Not sufficiently answered. I should be able to generate an S-record without RAM-based entries. RAM-based entries are only good during debug because the are lost on power-down. I am sure there is a way for the code generation tools to do this.

Can you please put me in contact with someone from the DSC compiler group that can answer this?

4) I am not sure if this duplicate entry of the code is a required procedure for creating copy-to-RAM functions. Or, if this is done just to create a RAM-copy to be available during debug. I am trying to get a copy-to-RAM function working in my LCF on-and-off for several weeks now. Understanding why and if the code needs to be duplicated would be helpful.

Can you please put me in contact with someone from the DSC compiler group that can answer this?

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

I have worked with the FAE, the forum, and opened a ticket with NXP. What will it take for me to get to an expert from the DSC compiler\LCF group?

[xiangjun_rong]

Hi, Jim,

Anyway,I think the Run_and_wait_in_RAM() function is only a architecture, which gives the start/end address so that the application can copy to the location.

This is the CodeWarrior development tools forum, you can post your question here about the compiler and LCF.

CodeWarrior Development Tools 

BR

Xiangjun Rong