Symbol F_vector_addr referenced from address 0x00000218 in section .text of file .... is too far away for a R_56800E_WORD16 relocation, which has a range from 0 to 131070 bytes

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

Symbol F_vector_addr referenced from address 0x00000218 in section .text of file .... is too far away for a R_56800E_WORD16 relocation, which has a range from 0 to 131070 bytes

Jump to solution
1,077 Views
dmitryrogachev
Contributor II

ERROR: Symbol F_vector_addr referenced from address 0x00000218 in section .text of file .... is too far away for a R_56800E_WORD16 relocation, which has a range from 0 to 131070 bytes

CHIP: MC56F8323 (probably is not important)

Hi!

 

Working on CW8.0 and 8.3 and trying to get access to the program address in memory, using the linker command  .cmd file, I often get this error

 

So, In linker command file it will be something like;

........................ cmd begins: ..........................................

MEMORY {

        # I/O registers area for on-chip peripherals

        .x_Peripherals (RW)   : ORIGIN = 0xF040, LENGTH = 0

 

        # List of all sections specified in the "Build options" tab

        #Internal vector boot area.

        .p_Interruptsboot  (RWX) : ORIGIN = 0x00020000, LENGTH = 0x0004

        .p_Interrupts  (RWX) : ORIGIN = 0x00000000, LENGTH = 0x000000A4

        .p_Code  (RWX) : ORIGIN = 0x000000A4, LENGTH = 0x00003F5C

        .x_Data  (RW) : ORIGIN = 0x00000001, LENGTH = 0x00000FFF

 

 

        # p_flash_ROM_data mirrors x_Data, mapping to origin and length

        # the "X" flag in "RX" tells the debugger flash p-memory.

        # the p-memory flash is directed to the address determined by AT

        # in the data_in_p_flash_ROM section definition

 

        .p_flash_ROM_data  (RX) : ORIGIN = 0x00000001, LENGTH = 0x00000FFF

 

        #Other memory segments

        .x_internal_ROM  (RW)  : ORIGIN = 0x00001000, LENGTH = 0x1000

        .p_internal_RAM  (RWX) : ORIGIN = 0x0002F800, LENGTH = 0x0800

 

}

 

KEEP_SECTION { interrupt_vectorsboot.text }

KEEP_SECTION { interrupt_vectors.text }

 

SECTIONS {

 

        .interrupt_vectorsboot :

        {

          F_vector_addr = .;

          # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AF

          # interrupt vectors boot area

          * (interrupt_vectorsboot.text)

        } > .p_Interruptsboot

 

.................... other sections..................................

.............................................................................

 

In the program:

extern void * _vector_addr;

 

========================================

I already changed the settings for the memory models for the assembler [EDIT/sdm pROM-xRAM Settings/M56800E Assembler] to

Default Data Memory Model of 24 bits and Program memory model of 19 bits. It should cover all the memory range within the memory map of my DSC. (56F8323)

 

How to avoid this error?

Thanks.

Labels (1)
Tags (2)
0 Kudos
Reply
1 Solution
968 Views
dmitryrogachev
Contributor II

His comments:

Solution       The problem is due to a compiler improvment.

In previous version the compiler generated 24 bits access when 16 bits was possible.

The DSC8.o generated "long" instruction to all structure's data fields which are below the first appearance of

the pointer, array or nested structure in large data model when "Globals live in lower memory" checkbox is checked.

With the DSC8.1 We were worked on removing this different behaviour of compiler in generating code for structure

fields at different offsets.

So this performance issue is addressed in the DSC8.1

Now the compiler always makes use of 16-bit access in "small data model" and "large data model + globals live in lower mem".

In your case, if you disable "globals live in lower mem" and it should link fine.

So disabling "globals live in lower mem" is one workaround that is unfortunately losing performance (size, speed).

Another possible solution is to write some simple assembly functions that return the addresses of the symbols with problem

and use those functions as interface with the C code.

This way the performance will not be affected by the "globals live in lower mem" option.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So, the proposed solution is to go to EDIT/project settings/Code Generation/M56800E processor  and change to the large DATA model, and don't check "Globals live in lower memory"

It works, but the linker generates another error: The file "MSL C 56800E.lib"  do not have the same memory model as the project.

So - what library should I use?

Regarding the libraries for the large memory model:

I loaded bootloader example; of cause this project had a large memory model.

It used the files:

Runtime 56800E lmm.lib from C:\Program Files\Freescale\CodeWarrior\M56800E Support\runtime_56800E\lib

and

MSL C 56800E LMM.lib from C:\Program Files\Freescale\CodeWarrior\M56800E Support\msl\MSL_C\DSP_56800E\lib

I substitute these files in Project window/support/lib and the project compiled ok.

View solution in original post

0 Kudos
Reply
2 Replies
969 Views
dmitryrogachev
Contributor II

His comments:

Solution       The problem is due to a compiler improvment.

In previous version the compiler generated 24 bits access when 16 bits was possible.

The DSC8.o generated "long" instruction to all structure's data fields which are below the first appearance of

the pointer, array or nested structure in large data model when "Globals live in lower memory" checkbox is checked.

With the DSC8.1 We were worked on removing this different behaviour of compiler in generating code for structure

fields at different offsets.

So this performance issue is addressed in the DSC8.1

Now the compiler always makes use of 16-bit access in "small data model" and "large data model + globals live in lower mem".

In your case, if you disable "globals live in lower mem" and it should link fine.

So disabling "globals live in lower mem" is one workaround that is unfortunately losing performance (size, speed).

Another possible solution is to write some simple assembly functions that return the addresses of the symbols with problem

and use those functions as interface with the C code.

This way the performance will not be affected by the "globals live in lower mem" option.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So, the proposed solution is to go to EDIT/project settings/Code Generation/M56800E processor  and change to the large DATA model, and don't check "Globals live in lower memory"

It works, but the linker generates another error: The file "MSL C 56800E.lib"  do not have the same memory model as the project.

So - what library should I use?

Regarding the libraries for the large memory model:

I loaded bootloader example; of cause this project had a large memory model.

It used the files:

Runtime 56800E lmm.lib from C:\Program Files\Freescale\CodeWarrior\M56800E Support\runtime_56800E\lib

and

MSL C 56800E LMM.lib from C:\Program Files\Freescale\CodeWarrior\M56800E Support\msl\MSL_C\DSP_56800E\lib

I substitute these files in Project window/support/lib and the project compiled ok.

0 Kudos
Reply
968 Views
dmitryrogachev
Contributor II

Regarding the libraries for the large memory model:

I loaded bootloader example; of cause this project had a large memory model.

It used the files:

Runtime 56800E lmm.lib from C:\Program Files\Freescale\CodeWarrior\M56800E Support\runtime_56800E\lib

and

MSL C 56800E LMM.lib from C:\Program Files\Freescale\CodeWarrior\M56800E Support\msl\MSL_C\DSP_56800E\lib

I substitute these files in Project window/support/lib and the project compiled ok.

0 Kudos
Reply