Regarding.....Linker files and Mem files

[tkvenki]

Hi All,

I'm a newbie for this platform. Please help me out in some concepts.

I have a made a board, based on the MCF5485EVB card.
My new card has an external flash and a external DDRAM.

Now to make the external flash and DDRAM accesible, what do I need to do?

* DO I need to change my .LCF file? ( Add a Flash section in the Memory)
* Do I need to change the .MEM file?(Allocate a section)


If I do not provide a section in the LCF file for the flash/DDRAM, what will happen?
Will I not be able to access them?
is it required to change the .mem file also?

Thanks
Venki

[SimonMarsden_de]

Hello Venki

You need to think about two separate concepts:

(a) You need to write code to initialise the hardware (e.g. the SDRAM controller) so that you can read and write from the memory

(b) You need to tell CodeWarrior what the memory map is, so that it can locate code appropriately - e.g. place code in Flash but place read/write data in RAM.

I'll give you a bit more detail so you can hopefully understand the overall structure....

Initialising the hardware
------------------------------
Imagine that the ColdFire processor is booting up and that no debugging cable is attached.

Initially, the boot program will be located in the Flash (external Flash on the MCF5485EVB). Until it takes steps to initialise them, some other resources like the SDRAM cannot be accessed.

The boot program usually starts off with some code in assembler to initialise a minimal environment - e.g. initialise the on-chip SRAM. It then carries out further initialisation of modules like the PLL and the SDRAM controller, the initialisation code for which can be written in C.

Once the whole processor is set up, control typically transfers to your 'main' procedure.

To see an example of boot code for the MCF5485EVB, try using CodeWarrior to generate a sample project from the stationery provided.

Faster Development
---------------------------
I just described how the processor is initialised when booting from Flash, which is what would happen in a final production device.

However, there are disadvantages to booting this way when you're writing code and want to test and debug it quickly - you have to keep erasing and re-flashing every time you change the program, and debugging code running from Flash is harder because you can usually only set one breakpoint at a time.

CodeWarrior provides a quicker way of developing/debugging, in which the code is downloaded to the board via the debug (BDM) cable. Instead of residing in Flash, the debugger places it in RAM - e.g. the SDRAM or the on-chip RAM. This is much quicker, and debugging is easier too.

If you generate a sample project from the CodeWarrior stationery you will see that it can build multiple targets, including the Flash/ROM version and the SDRAM version. If you build the Flash version you need to physically flash the device before you can run the code; the SDRAM version doesn't need to be flashed and is downloaded to the board via the BDM cable.

In order to be able to download code to the board, the debugger has to perform its own initialisation of the PLL and the SDRAM controller before it can write the code via the BDM cable. The commands needed to perform the initialisation are found in a configuration file with the extension ".cfg". They are in a simple command language which the debugger understands.

There will be one .cfg file for each CodeWarrior target. For the SDRAM target, the initialisation code which runs after the program is launched can be simpler than the Flash version, because the debugger has already initialised some of the peripherals.


Linker Control Files
-------------------------
A Linker Control File (LCF) is used to tell CodeWarrior where to place code and data - i.e where it will be located once the program is running. For example, code and read-only variables like strings might be placed in Flash, but read/write data needs to be in SRAM or SDRAM.

Note that the final location of the code and data once the program is running is not necessarily the same as its initial location. For example a processor which boots from Flash will need to copy the initial values of any read/write data from Flash into SDRAM at boot-up time.

There will be one LCF for each CodeWarrior target, each with the file extension ".lcf" (In the SDRAM target, code and data are both located in SDRAM). Take a look at the sample project for more information.

You only need to provide an LCF entry for the SDRAM if you want the CodeWarrior linker to locate anything there, so an entry is not strictly necessary. For example you could still access the SDRAM by reading/writing from absolute addresses:

    * (long *) 0x12340000 = 0;

However, this would be quite unusual.

Memory Files
-----------------
On some ColdFire processors, if you try to access non-existent memory the processor will hang. In addition, reading from some of the I/O registers can cause the processor to change state.

In CodeWarrior, you can use the debugger to dump memory by reading it over the BDM cable and displaying it on the PC. However, you wouldn't the board to hang just because you dumped the wrong memory address!

The ".mem" file tells the debugger the layout of the memory, so that it knows things like where the dead space is located.


I hope this is helpful. I suggest that you study the sample CodeWarrior project for the MCF5485EVB until you really understand how it all fits together.


Kind Regards


Simon

[francois_boucha]

Simon,

If I want to use the ext SDRAM (5282evb) along with the Flash, should I leave an entry for the SRAM in the linker file to?  Or can I just write one data address (the SDRAM base address)?