CodeWarrior for QorIQのトピックRe: Coldfire: Locating variables at fixed addresses

Coldfire: Locating variables at fixed addresses

jes — Thu, 10 Aug 2006 02:00:26 GMT

I'm using CodeWarrior 6.2 for a ColdFire processor. I'm trying to locate variables at specific locations in FLASH. According to several different methods I can use:

MATRIX stMatrixInNVM:0x0001e000;

#pragma define_section matrixdb ".matrixdb" RW
__declspec(matrixdb) MATRIX stMatrixInNVM;

// where above in .lcf

MEMORY
{
// flash       (RX) : ORIGIN = 0x00000000, LENGTH = 0x0001df80
flash       (RX) : ORIGIN = 0x00000000, LENGTH = 0x00040000
versioninfo (RW) : ORIGIN = 0x0001df80, LENGTH = 0x00000080
matrixdb   (RW)   : ORIGIN = 0x0001e000, LENGTH = 0x00002000
vectorsram (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400
sram      (RWX) : ORIGIN = 0x20000400, LENGTH = 0x00007c00
ipsbar     (RWX) : ORIGIN = 0x40000000, LENGTH = 0x0
}

SECTIONS

{

.matrixdb : {} > matrixdb

}

#pragma section .matrixdb begin

MATRIX stMatrixInNVM;

#pragma section .matrixdb end

Number 3. above is rejected by the compiler/linker/locator failing at the '.' Absent the '.' it fails at the "end" identifier.

Numbers 1 and 2 are accepted but stMatrixInNVM doesn't appear in the memory map .xMAP file at the expected address as defined. I thought perhaps it's there but just doesn't appear properly in the .xMap file. I examined the code in Mixed mode and the address used for stMatrixInNVM is 0x00000000 so it looks as though the linker never reconciled it to the defined address.

Can anyone help me out here and tell me how to make variables appear at specific addresses in FLASH with initial values.

This is fairly straightforward on the HCS08 by using the @ qualifier,

MATRIX stMatrixInNVM @ 0xfd00; or

const char sApp_VersionNum[] @0xf3b0= "00.02";

Thanks.

Message Edited by CrasyCat on 2007-04-13 11:14 AM

Re: Locating variables at fixed addresses

CrasyCat — Tue, 15 Aug 2006 21:03:46 GMT

Hello

Notation 3 is not working today. I have already reported that as a defect with our engineering team.

Notation 1 & 2 should be working.

When you use MATRIX stMatrixInNVM:0x0001e000 there is no formal object allocated at address 0x0001e000. The compiler is dealing with that as if it was a macro.

When you are accessing the object, the compiler will directly use the absolute address of the object.

Notation 2 should bring the object in the .map file.

There is just a small change requested in the .lcf file. Within SECTION block I would rather write:

.matrixdb: {*(.matrixdb)} > matrixdb

Is the object referenced within the application? If not you have to tell the linker you want to link that object even though it is not used.

This can be done using the linker command FORCE_ACTIVE in the lcf file.

I hope this helps.

CrasyCat

Re: Locating variables at fixed addresses

jes — Tue, 15 Aug 2006 23:02:51 GMT

Thanks for reply. I'm having difficulty with the syntax in general with the linker and as its presented in the documentation.

Note that I've also been in contact with a Freescale engineer for another defect in the linker/locator(which I believe has been reported). That is, if you include a 'const' specifier in the definition of a variable enclosed with a #pragma ...begin and #pragma ...end statements then the linker incorrectly locates the variable to RAM space rather than that specified in the section specifier of the pragma. The .xMAP file clearly shows this error. Most annoying since you'd most likely want to include a const specifier say for any variable located within FLASH space. Like a database for example that was written there and needs to be referenced on POR. Any such variables are never written to (other than through flash write routines which the compiler and linker/locator are not cognizant of) and thus the const specifier is appropriate.

The syntax of the #pragma define_section is also somewhat confusing. The doc defines as follows:

#pragma define_section sname ".istr" [.ustr] [addrmode] [accmode]

Parameters

sname

Identifier for source references to this user-defined section.

istr

Section-name string for initialized data assigned to this section. Double quotes must surround this parameter value, which must begin with a period. (Also applies to uninitialized data if there is no ustr value.)

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

The Section-name for istr above leads one to believe that it could be a section name as defined by the linker syntax:

SECTIONS { section_spec[, section_spec] }

Parameters

section_spec

sectionName : [AT (loadAddress)] {contents}
>segmentName

sectionName

Name for the output section, such as mysection. Must start with a period.

---------

However, I've only gotten the #pragma define_section to work correctly if the istr name is another name other than the sectionName above AND appearing within the {contents}. That is confusing and misleading.

Re: Locating variables at fixed addresses

CrasyCat — Wed, 16 Aug 2006 20:43:35 GMT

Hello

Only thing I can do here is report that back to doc team and ask for a better documentation.

On the constant stuff, did you specify R as AccessType in the corresponding define_section pragma?
R is the accessType for constant data.

I am not sure I get the point when you say "the istr name is another name other than the sectionName above AND appearing within the {contents}. "

Can you eventually give me a syntax which was not working and should have been correct according to your understanding.
I am afraid it is a little bit fuzzy for me

CrasyCat

Re: Locating variables at fixed addresses

jes — Wed, 16 Aug 2006 23:06:02 GMT

You wrote:

On the constant stuff, did you specify R as AccessType in the corresponding define_section pragma?
R is the accessType for constant data.

Yes, I did try the R specifier in the #pragma according to the allowed syntax and it was still improperly located to RAM. The R was also specified in the MEMORY segment defining the area of flash to which I wanted that 'variable' located. But if you think about it, providing an R explicitly in the pragma as a solution when using the const specifier doesn't make much sense when the absence of the const (implying that it is indeed r/w to the compiler anyway) correctly locates the 'variable' within the segment specified to flash. That is, if it properly locates to 'static' flash when you don't explicitly state R for a variable which is defined as something other than const then why would it not work when you're even more specific as to the variable's type? A 'developer' for Freescale (another SR which I'm currently discussing) also stated the following with respect to above:

Developer looked at this issue and he considers that this is not a bug.

He states that all "const" type must go to BSS segment (RAM) no matter

if they are declared in a pragma section.

To the above I'd just have to emphatically say HUH!!??? That's one of the points of declaring something const. Compiler will thwart any direct attempts to modify the variable declared as 'const' and linker will locate variable in flash space so as not to consume precious RAM space. Static strings, look-up tables declared as const, etc. all end up in flash and are fixed-up by linker to refer in code to their flash addresses.

You wrote:

I am not sure I get the point when you say "the istr name is another name other than the sectionName above AND appearing within the {contents}. "

Can you eventually give me a syntax which was not working and should have been correct according to your understanding.
I am afraid it is a little bit fuzzy for me

I'll try to make more clear what's also fuzzy to me. The "istr" description in the pragma define_section definition states that istr is a "section-name". sectionName is referred to in the LCF syntax as a name according to the SECTIONS{section-spec[,section-spec]} where sectionName is part of the sectionName : [AT (loadAddress)] {contents}
>segmentName

syntax. So, as an example, I ought to be able to do the following:

SECTIONS

{

.my_sectionName : {} >my_MEMORY_SEGMENT

}

#pragma define_section this_matrixdb ".my_sectionName" (R)
#pragma section this_matrixdb begin
MATRIX stMatrixInNVM;

#pragma section this_matrixdb end

However, the above doesn't work and linker reports an error as follows:

_stMatrixInNVM(.my_sectionName) in file matrix.c is referenced but has not been written.
Check your linker command file.

In order to get the pragma syntax accepted by linker and located to correct MEMORY segment then I must add an additional identifier within {} brackets of .my_sectionName above as follows and refer to this as "istr" in pragma statement:

.my_sectionName :

{ *(.my_additionalsectionName)
. =ALIGN(0x10);
} > my_MEMORY_SEGMENT

So, what does the linker error mean? In the original definition of .my_sectionName it refers to the MEMORY segment my_MEMORY_SEGMENT. So why isn't this sufficient and why do I need to define the additional .my_additionalsectionName? If above is required then why does syntax of #pragma define_section refer to istr as sectionName when it means rather something defined within the {contents} LCF syntax?

Re: Locating variables at fixed addresses

CrasyCat — Fri, 18 Aug 2006 17:28:48 GMT

Hello

I needed some time to go through that on.

I made some tests on both CW Coldfire V6.2 & V6.3.

First I would recommend you to use __declspec only to place an object is a specific section.

This is the only way you are going to get that working reliably.

On both version, if I define a constant (with const keyword), the constant is always allocated in .rodata section. Any __declspec modifier is in fact ignored.

This is s limitation in the compiler. All constants are allocated in section .rodata.

I could not get any constant into a .bss or .data section....

I defined my constants as

const int myConstData = 0x56;

Around the linker file behavior. Here is what I know about the linker file syntax.

A standard line in the .lcf file looks like:

.my_sectionName : {*(.my_sectionname)} >my_MEMORY_SEGMENT

The section name on the left is the name of the section as it should be generated in the executable file. The section name in the curly brackets is the section name as it appears in the object files generated by the compiler or assembler.

This has the big advantage of being completely open. You can use different section name in the object and executable file, you can merge several sections from the object files into one sections in the executable file, and so on.

I am not sure whether the notation

.my_sectionName : {} >my_MEMORY_SEGMENT

is working.

If you feed that is needed, go forward and submit a feature request through our web interface.

CrasyCat

Re: Locating variables at fixed addresses

jes — Fri, 18 Aug 2006 20:27:13 GMT

You wrote:

First I would recommend you to use __declspec only to place an object is a specific section.

This is the only way you are going to get that working reliably.

On both version, if I define a constant (with const keyword), the constant is always allocated in .rodata section. Any __declspec modifier is in fact ignored.

This is s limitation in the compiler. All constants are allocated in section .rodata.

I could not get any constant into a .bss or .data section....

I defined my constants as

const int myConstData = 0x56;

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

The "working reliably" statement above is disconcerting and I've found there are numerous things that this compiler/linker (6.2) does unreliably or incorrectly. That said--

I've also tried using the __declspec modifier and it has same limitation as the #pragma. That is, if the intended target MEMORY segment is in flash (and declared properly as R) and a const modifier is used then the 'variable' ends up in RAM. How's this you say since this contradicts with what you've found above in your myConstData example?

Don't specify the = 0x56 assignment and it will end up in RAM. Why, you ask, would you define a const and then not assign to it in the definition? Here's an example: Suppose you have a database an image of which you have in RAM. During normal execution the RAM image of the database is configured by user action. This database is expected to persist on loss of power so it's written to flash occasionally so that on a power-cycle it may be restored from previous settings. This is the reason for the const DATABASE myDatabaseInFlash definition. It is allocated an address at a specific location in flash so that on POR it can be read from and into the RAM database copy. Specifying const also informs the compiler to bark at any references made to it as writable. When written to flash (indirectly) the compiler isn't and shouldn't be cognizant of the fact that it's address in flash is being written to using appropriate flash write routines other than the fact that it's address in flash is referenced in preparation for the flash write.

If you're saying that the compiler syntax doesn't allow for definition of a 'variable' as const without specifically defining with an "= ..." at compiler time then the compiler ought to say so. Instead, the compiler happily accepts the lack of "=..." specification and allocates to RAM instead. That's not good and in my opinion is a bug/defect. Have the compiler spit out a warning or an error (I'm using 6.2).

(Where is the C BNF grammar listed in 6.2 Help by the way? I haven't been able to locate it and if I could have found const grammar then this would have been helpful and made for a quicker resolution. )

In regards to the .lcf syntax and section names, I think you've missed my point. Referring to every instance of use in the .lcf syntax and in the #pragmas (or elsewhere) as a section name does not promote a complete understanding of what is/is not acceptable syntax and only makes it more confusing. If references in #pragma is something other than sectionName as defined in .lcf syntax then call it something different. Doing otherwise is about as helpful as writing the same letter on every key of your keyboard but each actually representing something different and expecting the user to eventually figure out the transformation.

Thanks for looking into this.

Re: Locating variables at fixed addresses

CrasyCat — Mon, 21 Aug 2006 18:55:55 GMT

Hello

Well you are right, when the constant is not initialized, the variable gets allocated in .bss rather than .rodata section. The point here is that normally a constant data is not changing over execution time, so it should be initialized. It is normally good practice to initialize constant data.

On the other hand, ELF defines that all un-initialized variables should come into .bss section. So the compiler is not completely wrong either.

I would recommend to open a service request through the web for that one. We may get compiler engineers to modify this one.

If you have constant data that you know are initialized by some other means in the target board, you may want to define a pointer to that constant data and access the data through that pointer.

In ANSI C a pointer to an int is equivalent to a table of int. i.e. if you define a pointer to char variable, you can access it as an array.

So something like:
const int *myConstData = (int *)0x45000;
and access it as
tmp = myConstData[0];

This is fully legal in C.

We do not have ANSI C BNF notation in our manual as ANSI C is defined through ANSI C standard from ISO committee. So you found the BNF notation in the ISO manual or in any good ANSI C reference manual.

BNF notation from liker command file is available in the ColdFire_Build_Tools_Reference.pdf manual.

CrasyCat

Re: Locating variables at fixed addresses

RoughNeck — Sat, 06 Jan 2007 01:29:05 GMT

I have a similar problem.

I am porting a code from Diab compiler to CodeWarrior 8.1 for MPC555.

because of some available external memory some data is being placed on that address space.

there are some differences the way #pragma section statement works between two compilers.

I was able to port the code that works as follows

#ifdef __MWERKS__ // Changes for Metrowerks port - EA - 07/01/03

#pragma push
#pragma section RW ".abs.00980040"
#pragma section ".abs.00980040" ".abs.00980040" data_mode=far_abs

__declspec(section ".abs.00980040") extern T_dhp_nv_data_struct dhp_nv_data_struct;

#pragma pop
#else //Orginal Diab is below

#pragma section DHP_NV_DATA_Sect far-absolute RW address=0x00980040

#pragma use_section DHP_NV_DATA_Sect dhp_nv_data_struct;

extern T_dhp_nv_data_struct dhp_nv_data_struct;

#endif

above metrowerks code works, it creates the variable at correct location. I had to fiddle around with different options to get this working. Since this code is in the .h file where it is declared, but the action memory is allocated in the .c file.

however Metrowerks way does not allow me to crated a named section with a given address like Diab statement. Is there a way to do it? I do not want to do it in the LCF file, since I would like this to also work in the debug version where .lcf is not used. I was able to get MW to create a named section, or create it at an absolute address, but not both together like Diab Does.

This is the first question.

second question is:

I am having trouble making interrupt vectors defined at an address

Diab code is as follows
---------------
#pragma interrupt InterruptHandler
#pragma interrupt InterruptHandler

#pragma section ProgSect address=0x940000
#pragma use_section ProgSect InterruptMachine
#pragma section ProgSectII address=0x940100
#pragma use_section ProgSectII InterruptHandler
----------

I checked the Metrowerks targeting manual but could not find a corresponding way to place Interrupt routines at certain address.

following statement defines interrupt routine but not at an address

__declspec(interrupt) void InterruptHandler()

#pragma interrupt on
void InterruptHandler(void)
{

myRoutine()

}

#pragma interrupt off

also Diab way first defines where the function will be placed and then function is declared later on, can you do that with CodeWarrior?

Cheers

Re: Locating variables at fixed addresses

sjmelnikoff — Mon, 23 Apr 2007 16:21:24 GMT

jes wrote:
Compiler will thwart any direct attempts to modify the variable declared as 'const' and linker will locate variable in flash space so as not to consume precious RAM space.

I've also been struggling to place constants in specific areas of flash. I eventually plan to use this for a copyright notice and CRC, but started with the CFM constants, which are normally declared in an assembler file.

This is what I did to get it working. In the .c file:

#pragma define_section _Flash_CFM ".Flash_CFM_Data" far_absolute R
#pragma section _Flash_CFM begin
/* CFM Flash Configuration Field */
/* 0x0400 Backdoor Comparison Key - High */
u32 u32KEY_UPPER = 0x00000000;
/* 0x0404 Backdoor Comparison Key - Low */
u32 u32KEY_LOWER = 0x00000000;
/* 0x0408 Flash Protection Bytes */
u32 u32CFMPROT   = 0x00000000;
/* 0x040C Flash SUPV Access Bytes */
u32 u32CFMSACC   = 0x00000000;
/* 0x0410 Flash DATA Access Bytes */
u32 u32CFMDACC   = 0x00000000;
/* 0x0414 Flash Security Word */
u32 u32CFMSEC    = 0x00000000;
#pragma section _Flash_CFM end

As Jes found, declaring these as "const" doesn't work.

In the linker file:

FORCE_ACTIVE{_u32KEY_UPPER, _u32KEY_LOWER, _u32CFMPROT, _u32CFMSACC, _u32CFMDACC, _u32CFMSEC}
...

SECTIONS
{
.Flash_CFM:
{
*(.Flash_CFM_Data)
} > Flash_CFM

Note that the FORCE_ACTIVE line only seems to work if you put it before the SECTIONS block!!! The documentation does not make this clear!

As has been mentioned, putting constants in specified areas of flash is an important thing to be able to do, and the tools make it very difficult.

What is additionally frustrating is that, in the previous project I worked on, which used CodeWarrior for HCS12, doing this was much easier - and it worked without the workarounds required for the ColdFire edition.

Steve.

Re: Locating variables at fixed addresses

sjmelnikoff — Mon, 23 Apr 2007 16:55:39 GMT

In my previous post, I forgot to include this in the linker file excerpt:

MEMORY
{
   ...
  Flash_CFM      (R)   : ORIGIN = 0x00000400, LENGTH = 0x00020
   ...
}

Steve.

Re: Coldfire: Locating variables at fixed addresses

sjmelnikoff — Mon, 23 Apr 2007 17:07:02 GMT

I take it all back. The linker does correctly allocate the space - but doesn't initialise the data

Any suggestions?

Steve.

Re: Locating variables at fixed addresses

CrasyCat — Mon, 23 Apr 2007 17:29:12 GMT

Hello

I did perform some tests.

Defining the constants as follows seems to do the trick:

Code:

#pragma push /* Save the compiler’s state. */
#pragma section data_type const_type ".Flash_CFM_Data" ".Flash_CFM_Data" data_mode=far_abs/* CFM Flash Configuration Field */
/* 0x0400 Backdoor Comparison Key - High */
unsigned long u32KEY_UPPER = 0x00000000;
/* 0x0404 Backdoor Comparison Key - Low */
unsigned long u32KEY_LOWER = 0x00000000;
/* 0x0408 Flash Protection Bytes */
unsigned long u32CFMPROT   = 0x00000000;
/* 0x040C Flash SUPV Access Bytes */
unsigned long u32CFMSACC   = 0x00000000;
/* 0x0410 Flash DATA Access Bytes */
unsigned long u32CFMDACC   = 0x00000000;
/* 0x0414 Flash Security Word */
unsigned long u32CFMSEC    = 0x00000000;
#pragma pop /* Save the compiler’s state. */

Attached sample ANSI C and .lcf file I have been using.

I did the test with CW MCP5xx V8.7.

If you want to define a section allocated at an absolute address you may want to try the following:

#pragma push

#pragma section code_type ".abs.00010000" code_mode=pc_rel

void func(void)

{

}

#pragma pop

I get it working on an earlier version of CodeWarrior EPPC. I did not try it with the latest release I should admit.

otherwise you can use pragma section and also use a .lcf file in debug mode.

I would recommend this approach anyway as lcf files are much more flexible than the EPPC Linker Panel.

CrasyCat

testcst.zip

Message Edited by t.dowe on 2009-09-04 11:32 AM

Re: Locating variables at fixed addresses

sjmelnikoff — Mon, 23 Apr 2007 17:49:58 GMT

Hi CrasyCat. Thanks for responding so quickly.

This syntax for #pragma section is not supported for ColdFire. The CodeWarrior Build Tools Reference ColdFire™ Architectures Edition manual states:

Activates or deactivates a user-defined or predefined section.
#pragma section sname begin | end

The only way I've been able to get this to work is to do it in assembler. In FlashReg.s:

.export u32KEY_UPPER
.export u32KEY_LOWER
.export u32CFMPROT
.export u32CFMSACC
.export u32CFMDACC
.export u32CFMSEC
.section .text
/* CFM Flash Configuration Field */
u32KEY_UPPER: .long   0x00000000 /* 0x0400 Backdoor Comparison Key */
u32KEY_LOWER: .long   0x00000000 /* 0x0404 Backdoor Comparison Key */
u32CFMPROT:    .long   0x00000000 /* 0x0408 Flash Protection Bytes */
u32CFMSACC:    .long   0x00000000 /* 0x040C Flash SUPV Access Bytes */
u32CFMDACC:    .long   0x00000000 /* 0x0410 Flash DATA Access Bytes */
u32CFMSEC:     .long   0x00000000 /* 0x0414 Flash Security Word */
.end

In the linker file:

FORCE_ACTIVE
{
  u32KEY_UPPER, u32KEY_LOWER, u32CFMPROT, u32CFMSACC, u32CFMDACC, u32CFMSEC
}
...
SECTIONS
{
  .Flash_Reg:
   {
     FlashReg.s (.text)
   } > Flash_Reg
  ...
}

It really shouldn't be this difficult...

Steve.

Re: Locating variables at fixed addresses

CrasyCat — Mon, 23 Apr 2007 19:36:30 GMT

Hello

OK I have been confused as the beginning of the thread was speaking about MPC5xx and the end of the thread about Coldfire .

As CodeWarrior might behave differently for different targets, it would be much clearer in the future to

start separate threads for different target.

When you are building for Coldfire, you need to define the constants as follows:

Code:

#pragma define_section _Flash_CFM ".Flash_CFM_Data"  far_absolute R#pragma explicit_zero_data on__declspec(_Flash_CFM)  unsigned long _cfm[6] = {/* CFM Flash Configuration Field *//* 0x0400 Backdoor Comparison Key - High */__declspec(_Flash_CFM) u32 u32KEY_UPPER = 0x00000000;/* 0x0404 Backdoor Comparison Key - Low */__declspec(_Flash_CFM) u32 u32KEY_LOWER = 0x00000000;/* 0x0408 Flash Protection Bytes */__declspec(_Flash_CFM) u32 u32CFMPROT   = 0x00000000;/* 0x040C Flash SUPV Access Bytes */__declspec(_Flash_CFM) u32 u32CFMSACC   = 0x00000000;/* 0x0410 Flash DATA Access Bytes */__declspec(_Flash_CFM) u32 u32CFMDACC   = 0x00000000;/* 0x0414 Flash Security Word */__declspec(_Flash_CFM) u32 u32CFMSEC    = 0x00000000;

One of the trick here is that if your constant are initialized with 0, the compiler is performing a so called optimization (I hate it too) and is placing the constants in .bss.

In order to prevent that from happening you need to use the pragma

#pragma explicit_zero_data on
prior to defining the constants.

Also I noticed the pragma section begin ... pragma section end are not always working as expected.

I would recommend using __declspec to place an object in a specific section. This is working more reliably for Coldfire.

CrasyCat

Re: Locating variables at fixed addresses

sjmelnikoff — Mon, 23 Apr 2007 20:18:44 GMT

That did the trick! Thank you CrasyCat!

Steve.

Re: Coldfire: Locating variables at fixed addresses

TrevorCurry_eu — Tue, 09 Oct 2007 20:54:53 GMT

Hello,

I have only just started porting to the ColdFire MCF5223evb and have a requirement to fix an array in Flash. I have tried the suggestions here but think I have become confused in the various earlier iterations.

My array is defined as:

#pragma define_section _MacAddr ".MacAddr" far_absolute R
#pragma explicit_zero_data on
//Declare the non-volatile array fixed in Flash
__declspec (_MacAddr) unsigned char mac_addr[6] = {0x00, 0x0a, 0x8D, 0x0, 0x00, 0x1E};

...and I have the following in my linker file:

MEMORY
{
    rom     (RX) : ORIGIN = 0x00000000, LENGTH = 0x0001FFF0
    MacAddr (RX) : ORIGIN = 0x0001FFF0, LENGTH = 0x00000010
    ram     (RW) : ORIGIN = 0x20000000, LENGTH = 0x00008000
}

...but the build issues the following:

_mac_addr(.MacAddr) in file mac_id.c is referenced but has not been written.
Check your linker command file.

...and the mac_addr is missing from the xMAP file.

I am obviously missing something but what?

Cheers,
Trevor

Re: Coldfire: Locating variables at fixed addresses

CrasyCat — Wed, 10 Oct 2007 17:15:56 GMT

Hello

Check the Build Tools reference manual.

The name of the section should not be specified in the MEMORY block, but in the SECTIONS block.

So I would change the MEMORY block as follows:

MEMORY
{
    rom     (RX) : ORIGIN = 0x00000000, LENGTH = 0x0001FFF0
    MAC_Mem(RX) : ORIGIN = 0x0001FFF0, LENGTH = 0x00000010
    ram     (RW) : ORIGIN = 0x20000000, LENGTH = 0x00008000
}
and add the following to the SECTIONS block
    .MacAddr : {

*(.MacAddr)

} > .MAC_Mem

CrasyCat

Re: Coldfire: Locating variables at fixed addresses

TrevorCurry_eu — Wed, 10 Oct 2007 18:11:55 GMT

Hi,

Many thanks for that - I am not sure I could have figured out the syntax of the *(.MacAddr) entry for the contents field from the manual description (p112).

Just a minor change, the segment name in SECTIONS does not need the '.'

   .MacAddr : {
         *(.MacAddr)
     } > MAC_Mem

The xMAP file now confirms that I have a separate .MacAddr memory area at the required address with the mac_addr[] array correctly populated - great!

Many thanks for your speedy response!
Trevor

Re: Coldfire: Locating variables at fixed addresses

TT — Thu, 10 Jan 2008 23:35:55 GMT

Hi,

I tried to use the same piece of code to define an array at fixed location.

#pragma define_section _MacAddr ".MacAddr" far_absolute R
#pragma explicit_zero_data on

__declspec (_MacAddr) unsigned char mac_addr[6] = {0x00, 0x0a, 0x8D, 0x0, 0x00, 0x1E};

and in lcf

MEMORY
{
    CODE (RX) : ORIGIN = 0x00000000, LENGTH = 0x00700000
    RAM (RW) : ORIGIN = 0x00800000, LENGTH = 0x01800000
    ROM (RX) : ORIGIN = 0x51900000, LENGTH = 0x00600000
    MAC_Mem(RX) : ORIGIN = 0x52500000, LENGTH = 0x00010000

}

FORCE_ACTIVE {VECTOR_TABLE,mac_addr}

and add the following to the SECTIONS block
   .MacAddr : {
         *(.MacAddr)
       } > MAC_Mem

Here Linker Complains:

"The symbol "mac_addr" was forced in the link with a "FORCE_ACTIVE" clause
but no definition could be found."

Map file looks like:

# Memory map:
v_addr   p_addr   size     name
00000000 00000000 00000CE8 .boot_ram CODE
00000CE8 51900CE4 00109112 .main_application CODE
00800000 51A09DF6 00032268 .main_application_data RAM
00832268 00832268 000631A0 .uninitialized_data RAM
00895408 51A3C05E 00000030 .romp      RAM
51900000 51900000 00000CE4 .boot      ROM
52500000 52500000 00000000 .MacAddr   MAC_Mem

Can anyone help me to figure out the problem? Why linker is not finding the definition?

Thanks All,