Codewarrior Code and variable relocation

[guitardenver]

I'm using Codewarrior 10.6.4 for a target of the Coldfire V1 MCF51JE256RM. I am trying to force some RAM variables to specific addresses but I can't seem to find the correct syntax.

I have tried the @0x00000 way like below

uint_8 g_recv_size@0x805A05;

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

I have tried the __attribute((section (".myBufSection"))); Like below

uint_8 g_recv_size __attribute__((section (".myBufSection"))); 

and edited the linker file 

/* placing my named section at given address: */
.myBufBlock 0x805A05 :
{
KEEP(*(.myBufSection)) /* keep my variable even if not referenced */
} >> userram

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

I have tried the #pragma approach. This gives me "end of line expected" errors

#pragma define_section mySectionInRAM “.myCodeInRAM” far_absolute RX
#pragma section mySectionInRAM begin

uint_8 g_send_size;

#pragma section mySectionInRAM end

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

I have tried the __delspec((section (".myBufSection"))); Like below

__delspec((section (".myBufSection"))) uint_8 g_recv_size; 

and edited the linker file 

/* placing my named section at given address: */
.myBufBlock 0x805A05 :
{
KEEP(*(.myBufSection)) /* keep my variable even if not referenced */
} >> userram

What is the proper way to do this seemingly simple task? I want to force a variable to a specific RAM address.

[guitardenver]

So it turns out the @0x...... method does work.

For Example:

uint_8 g_recv_size@0x805A05;

This works great by itself. But I also have an assembly file that uses this variable. 

So my assembly code looks like the following:

.extern _g_recv_size 

For some reason, everything works great when I do not have the "@0x805A05" on the variable declaration. But when it is there, the compiler says the variable referenced by my ".extern _g_recv_size" is undefined. I did notice that in the .xMAP file, when the "@0x805A05" is present, the variable in the .xMAP file is renamed "abs_g_recv_size". 

Changing the assembly code to say:

.extern _abs_g_recv_size

does not work.

Any thoughts on what is going on here?

[ZhangJennie]

Hi Matt,

Could you please upload your demo project here?

Thanks.

Jennie Zhang.

[guitardenver]

We did not find a solution to the problem. But we did decide to go another route that allowed us to not need to put the variables that we reference in assembly at specific addresses. 

I do not have demo project, this is on production code that I can not upload. But to replicate the issue:

1) Define a variable in C and use the "@" symbol to specify a certain address

2) In an assembly code file, use the ".extern" to include it into the assembly code

3) Reference the variable in assembly code somewhere.

4) You should get errors in the build.

5) Remove all reference to the variable in assembly

6) The build should work now.

Maybe load up the USB CDC demo project and use the g_recv_size variable in the virtual_com.c as the variable like I am.

[ZhangJennie · Accepted solution]

Matt,

I just tested to reference c variable in assembly, there is no build error. see below screenshot

C source code:

asm source code:

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[guitardenver]

Your code found the answer.

In my code, the C variable is declared like so:

uint_8 g_recv_size@0x805A05;

And the assembly extern is:

.extern _g_recv_size

The "_" symbol in front of it was causing the issues. For some reason the assembly code can use the variable just fine with the "_" with no "@0x805A05". But once the "@0x805A05" is there, you must remove the "_" for it to work.

So my question is, why does it work with "_" in front of it at all? For C functionions I reference in assembly, I must put the "_" in front of it in assembly for it to work.

Is there a reason for the "_", or is this a bug in the assembler?

[ZhangJennie]

yes, Thank you for pointing it out.

I will escalate it to CW IDE development team.

Currently, please work out your problem with the wrokaround I provided.

Have a great day,
Jennie Zhang

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------