Linker Error: symbol too far way for a R_56800E_BYTE16 relocation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Linker Error: symbol too far way for a R_56800E_BYTE16 relocation

2,957 Views
Dime
Contributor I
I am using a 56f8345 micro with CodeWarrior 7.3. 

In my program I have created many byte arrays for storing screen and field data.  I specified that these arrays should reside in the program flash.  Here is an example of one such array:

__pmem const byte S_PA_LOW[] =
{
    HED,
    POS, 41, 'L','o','w',' ','L','i','m','i','t',':', DWN, END
};

This worked great early on.  After a while, however, I began receiving many linker errors similar to the following: symbol FS_PA_LOW referenced from address 0x00011830 in section .data.pmem is too far way for a R_56800E_BYTE16 relocation, which has a range of 0 to 65535 bytes.

Anyone out there have a good explanation of what is going on?  Any ideas on a solution?


Labels (1)
Tags (1)
0 Kudos
4 Replies

790 Views
J2MEJediMaster
Specialist I
The linker error message says it all. The array elements are being referenced using a 16-bit value, and the contents of your array have grown larger than what can be addressed using sixteen bits. You're going to have to either break the array up, or make the compiler generate a 32-bit offset for your array. Check the compiler and linker documentation for information on how accesses to arrays are implemented.

---Tom


Message Edited by J2MEJediMaster on 2007-09-26 10:13 AM
0 Kudos

790 Views
Dime
Contributor I
Thanks for the reply.  Please excuse my ignorance as I try to get a better picture of what is going on. 

In my program I have many small arrays.  None of the arrays are greater than 80 bytes long.  So I'm confused by your comments that the contents of my array have grown larger than what can be addressed using sixteen bits.  In my opinion I have a different problem.  Let me try to clarify my situation.  I have a constant array that holds information about all of my screens (number of fields, screen type, etc...).  As part of this array there are pointers to the actual arrays that contain the data that makes up the screen.  It seems to me like the linker error message is indicating that the screen data arrays are located too far away from the array that references them.  All of these arrays, however, are declared as __pmem const byte arrays. 

In the process of "just trying things" I enabled Large Memory Model support in the project options.  I then included the appropriate large memory model run time libraries.  This "fixed" my problem, however, I'm not sure I fully understand the all of the differences between large and small memory models. 

Does this solution make sense to you?  Can you point me in the direction of a good document that lays out how each of the different memory models work?

Thank You
0 Kudos

790 Views
J2MEJediMaster
Specialist I
The pointers used to reference the arrays used only 16 bits, and so when you had enough arrays that required the use of a memory space larger than could be accessed by sixteen-bit pointer, you got the error.

I'm not that familiar with the ColdFire memory models, but I can speak to your fix in general terms. A small memory model means everything fits (typically) within 64KB of memory. Or, code occupies one 64KB region, and data another 64KB region. Pointers are therefore, sixteen bits in size.

A large memory model can access memory regions larger than 64 KB. Depending upon the MCU, the pointers might be 24- or 32-bits in size in order to reference the larger memory regions. The compiler can be instructed to generate the appropriate code and pointer size if you specify a memory model during compilation. The large memory model compilation fixed your problem because the 32-bit pointers the compiler generated were capable of addressing all of your arrays.

The memory model scheme serves to optimize the code for applications that either use a small amount of data (small model) or a large amount (large model).

---Tom
0 Kudos

790 Views
Dime
Contributor I
J2MEJediMaster,

Thanks for your insight!
0 Kudos