ColdFire/68K Microcontrollers and Processors中的主题 Re: what these lines mean in .lcf file

what these lines mean in .lcf file

doom — Sat, 16 May 2009 08:45:15 GMT

Here is my .lcf file and someting puzzling me...

# Sample Linker Command File for CodeWarrior for ColdFire

# Memory ranges

MEMORY {
vectorrom (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000420
code (RX) : ORIGIN = 0x00000500, LENGTH = 0x0001Fae0

my (RX) : ORIGIN = 0x0001fae0, LENGTH = 0x00000100

vectorram (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400
userram (RWX) : ORIGIN = 0x20000400, LENGTH = 0x00007c00
}

SECTIONS {

# Heap and Stack sizes definition
___heap_size = 0x1000;
___stack_size = 0x1000;

# MCF5213 Derivative Memory map definitions from linker command files:
# __IPSBAR, __RAMBAR, __RAMBAR_SIZE, __FLASHBAR, __FLASHBAR_SIZE linker
# symbols must be defined in the linker command file.

# Memory Mapped Registers (IPSBAR= 0x40000000)
___IPSBAR = 0x40000000;

# 32 Kbytes Internal SRAM
___RAMBAR = 0x20000000;
___RAMBAR_SIZE = 0x00008000;

# 256 KByte Internal Flash Memory
___FLASHBAR = 0x00000000;
___FLASHBAR_SIZE = 0x00040000;

.userram : {} > userram
.code : {} > code
.vectorram : {} > vectorram
.vectorrom : {} > vectorrom

.absd:
{

*(.MacAddr)
= ALIGN (0x4);
} > my
.vectors
{
mcf5xxx_vectors.s (.text)
. = ALIGN (0x4);
} >> vectorrom

.text :
{
*(.text)
. = ALIGN (0x4);

*(.rodata)
. = ALIGN (0x4);

___ROM_AT = .;
___DATA_ROM = .;
} >> code
.data : AT(___ROM_AT)
{
___DATA_RAM = .;
. = ALIGN(0x4);
*(.exception)
. = ALIGN(0x4);
__exception_table_start__ = .;
EXCEPTION
__exception_table_end__ = .;

___sinit__ = .;
STATICINIT
__START_DATA = .;

*(.data)
. = ALIGN (0x4);
__END_DATA = .;

__START_SDATA = .;
*(.sdata)
. = ALIGN (0x4);
__END_SDATA = .;

___DATA_END = .;
__SDA_BASE = .;
. = ALIGN (0x4);
} >> userram

.bss :
{
___BSS_START = .;
__START_SBSS = .;
*(.sbss)
. = ALIGN (0x4);
*(SCOMMON)
__END_SBSS = .;

__START_BSS = .;
*(.bss)
. = ALIGN (0x4);
*(COMMON)
__END_BSS = .;
___BSS_END = .;

. = ALIGN(0x4);
} >> userram

.custom :
{
___HEAP_START = .;
___heap_addr = ___HEAP_START;
___HEAP_END = ___HEAP_START + ___heap_size;
___SP_END = ___HEAP_END;
___SP_INIT = ___SP_END + ___stack_size;

. = ALIGN (0x4);
} >> userram

___VECTOR_RAM = ADDR(.vectorram);

__SP_INIT = ___SP_INIT;

_romp_at = ___ROM_AT + SIZEOF(.data);
.romp : AT(_romp_at)
{
__S_romp = _romp_at;
WRITEW(___ROM_AT);
WRITEW(ADDR(.data));
WRITEW(SIZEOF(.data));
WRITEW(0);
WRITEW(0);
WRITEW(0);
}

}

what these lines mean?
.userram : {} > userram
.code : {} > code
.vectorram : {} > vectorram
.vectorrom : {} > vectorrom

Can I delete them?
I also define a section myself and not use command like that and it is ok!
why? What is the different between my section and others?
Can anyone explain it?

doom

Re: what these lines mean in .lcf file

CrasyCat — Sun, 17 May 2009 17:17:10 GMT

Hello

The lines

.userram : {} > userram
.code : {} > code
.vectorram : {} > vectorram
.vectorrom : {} > vectorrom

Indicates that you are placing the section .userram from your application in the memory area userram, section .code into memory area code, section .vectorram in memory area vectorram and section vectorrom in section vectorrom.

If you are sure these sections are not used at all in your application, you can remove the lines from the .lcf file.

I would try to link the application as it is and check the generated .map file to make sure the sections really do not exist in your final application.

CrasyCat

Re: what these lines mean in .lcf file

EdProulx — Fri, 31 Jul 2009 01:33:37 GMT

My issue is that I would like to load my application into flash at a specific address (my goal: eventually download a 2nd application to yet some other flash location, and when the system is reset, execute using this newly downloaded application).

In my .lcf link control file, I specify:

MEMORY {
   vectorrom   (RX) : ORIGIN = 0x00002000, LENGTH = 0x00000400
   cfmprotrom (RX) : ORIGIN = 0x00002400, LENGTH = 0x00000020
   code        (RX) : ORIGIN = 0x00002A00, LENGTH = 0x0003FB00
   vectorram   (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400
   userram     (RWX) : ORIGIN = 0x20000400, LENGTH = 0x00007C00
}

This will load and launch my application in flash from 0x2A00. The vector table is located in 0x2000 which I verify via the debugger, data is valid. But the system crashes ("Exception name vector: Address Error") if I "Run" it or attempt to step through the _startup entry routine.

If vectorrom is not at 0x00000000 then the system crashes - always. If the vectorrom is at the ZERO address, the system runs fine, entering the "code" as per its specification in the MEMORY section. So I can run code from anywhere in flash. But I need to have the vector table in flash also at a specific location in flash.

Any help to get me past this problem would be greatly appreciated.

Re: what these lines mean in .lcf file

PaoloRenzo — Fri, 31 Jul 2009 10:14:29 GMT

Seems like you're using an MCU

flashbar always always starts at zero after each reset, then will start to look for vector table at zero.

you're lucky to start debugging code since you're using the debugger, which fixes these values using cfg file. you will not be able to see anything in standalone mode

you can change flashbar at runtime, not at the beggining

in my opinion, i don't think it's necessary to change flashbar even at runtime, seems more useful for MPUs with external memory

have you seen the first two longwords at vector table? those point to starting address and SP initial value

does this make sense to you or i completely misunderstood your question?

Re: what these lines mean in .lcf file

EdProulx — Fri, 31 Jul 2009 22:56:48 GMT

Actually, it makes perfect sense. Not good sense, but perfect. In fact, it was only after I posted that I was reading the ColdFire MCF52259_CMRM reference manual, where in section "3.2.6 Vector Base Register (VBR)" it states:

The VBR contains the base address of the exception vector table in memory. To access the vector table,the displacement of an exception vector is added to the value in VBR. The lower 20 bits of the VBR are not implemented by ColdFire processors. They are assumed to be zero, forcing the table to be aligned on a 1 MByte boundary

Well, I have 512K of flash. So the vector table *MUST* reside at address 0x0, so it cannot be moved elsewhere.

Now that I understand this aspect more clearly, I have to consider other alternative solutions to reach my goal.