Coldfire: Locating variables at fixed addresses

jes · ‎08-09-2006

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:

1.

MATRIX stMatrixInNVM:0x0001e000;

or

2.

#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

}

or

3.

#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,

eg

MATRIX stMatrixInNVM @ 0xfd00; or

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

Thanks.

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

TrevorCurry_eu · ‎10-09-2007

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

CrasyCat · ‎10-10-2007

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

TrevorCurry_eu · ‎10-10-2007

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

TT · ‎01-10-2008

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,

TT

CrasyCat · ‎01-11-2008

Hello

If I remember well the coldfire compiler ads a _ prefix to symbol names.

Can you try

FORCE_ACTIVE {VECTOR_TABLE, _mac_addr}

CrasyCat

TT · ‎01-11-2008

You got it right Crystcat. After adding "_" to symbol name I can see this in MAP file.

Thanks a lot!!!

While doing this stuff I came across one more things very much similar to this:

My aim is to add a hex file with code warrior output on fixed location. For this I converted hex file to bin file and tried to place it at the fixed address as follows:

.MacAddr :
{
       _CAN_LIOStart = .;
      INCLUDE CAN_LIO.mid
      _CAN_LIOEnd = .;

     } > MAC_Mem

I made all the required changes in project settings to mark a bin file as resource file.

In this case linker complains that it did not find the file CAN_LIO.

If I add "-" to file name (INCLUDE _CAN_LIO.mid) then CW crashes.

I would really appriciate if you can give me some workaround to add a bin file into project at a predefined location.

Regards,

Trilok

Arev · ‎01-14-2008

Hello,

In my project i use binary files with .bin extension as following:

.file :
{
__FileStart = .;

INCLUDE Signaux_00.bin

__FileEnd = .;

} >> RAM_ProgSector

Don't forget to add the binary file in your project and to configure the project for the new extension (if not .bin) in Project settings/Target/File Mapping with the same parameters as .bin.

My project uses CW Compiler/linker with command line and the only extension i can use is .bin

I Hope this helps..

Bye

<< Freescale MCF5234/35 with CodeWarrior 6.2 >>

sjmelnikoff · ‎04-23-2007

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

Any suggestions?

Steve.

RoughNeck · ‎01-05-2007

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()

or

#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

CrasyCat · ‎08-15-2006

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

jes · ‎08-15-2006

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.

CrasyCat · ‎08-16-2006

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

jes · ‎08-16-2006

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?

sjmelnikoff · ‎04-23-2007

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.

sjmelnikoff · ‎04-23-2007

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

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

Steve.

CrasyCat · ‎04-23-2007

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

sjmelnikoff · ‎04-23-2007

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.

CrasyCat · ‎04-23-2007

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

sjmelnikoff · ‎04-23-2007

That did the trick! Thank you CrasyCat!

Steve.

CrasyCat · ‎08-18-2006

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

Coldfire: Locating variables at fixed addresses

Coldfire: Locating variables at fixed addresses

General