Link Error L1907 - How to fix it?

cancel
Showing results for 
Search instead for 
Did you mean: 

Link Error L1907 - How to fix it?

Jump to solution
3,391 Views
sebasira
Senior Contributor I

Hi all! I've got a problem here.. I already search in CodeWarrior Help, and I guess the problem is due to zero paged variables allocated out of the zero page.

 

This is the error I get:

 

Link Error: L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB

Link Error: L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0x13

Link Error: L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0x19

Link Error: L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0x20

 

Then looking at the map file I see this:

_NEG_P                                    FEE2       F        15       0   NON_BANKED  
_LDIVS                                       75C7      35      53       0   FLASH_PAGE7000_304

 

I have several targets in my project, some of them don throw this error and both _NEG_P and _LDIVS are allocated in the same page.

 

Also, my pages are called:

FLASH_PAGEC000

FLASH_PAGE7000

PAGE_31 ..... to ..... PAGE_3D

 

And don't know why, the compiler "creates" FLASH_PAGE7000_304. What am I forgetting or doing wrong? (also sometimes creates PAGE_3D_### and other pages too)

 

Well, I hope you guys can help me here. I don't know how to allocate those objects since they are part of ansibi.lib.

 

Just if you need it, here's part of my .prm file:

 

PLACEMENT

    PAGE_7000              INTO  FLASH_PAGE7000;    

    _PRESTART,                   /* Used in HIWARE format: jump to _Startup at the code start */
    STARTUP,                     /* startup data structures */
    ROM_VAR,                     /* constant variables */
    STRINGS,                     /* string literals */
    VIRTUAL_TABLE_SEGMENT,       /* C++ virtual table segment */
    NON_BANKED,                  /* runtime routines which must not be banked */
    PAGE_C000,
    PAGE_IRQ,
    COPY                                     INTO  FLASH_PAGEC000,FLASH_PAGE7000;

 

Thanks in advance!

Labels (1)
1 Solution
612 Views
CrasyCat
Specialist III

Hello

 

In case you use two non contiguous memory area to store the section NON_BANKED make sure to build your application and the ANSI library with option -OnB=b.

 

If you create your project using the wizard, the original .prm file contains following comment:

                           /* in case you want to use ROM_4000 here as well, make sure
                              that all files (incl. library files) are compiled with
                              the option: -OnB=b */
              INTO  ROM_C000/*, ROM_4000*/;

 This options makes sure the compiler does not attempt to replace a JSR with a BSR.

 

 Alternatively you can try moving the section NON_BANKED up in the list of sections to allocate into FLASH_PAGEC000,FLASH_PAGE7000

 

PLACEMENT
   NON_BANKED, /* runtime routines which must not be banked */
   _PRESTART, /* Used in HIWARE format: jump to _Startup at the code start */
   STARTUP, /* startup data structures */
   ROM_VAR, /* constant variables */
   STRINGS, /* string literals */
   VIRTUAL_TABLE_SEGMENT, /* C++ virtual table segment */
   PAGE_C000, PAGE_IRQ, COPY
                           INTO FLASH_PAGEC000,FLASH_PAGE7000;

    PAGE_7000              INTO  FLASH_PAGE7000;   

 

CrasyCat

View solution in original post

4 Replies
612 Views
Lundin
Senior Contributor IV

Zero page? What MCU are you using? S12 non-fixed flash is typically located at 8000 and C000 respectively, but on S12 the zero page is optimized for on-chip registers rather than user data, and is best kept that way.

 

Why are you storing PAGE_C000 in FLASH_PAGE7000 for? This could be one cause of the problems.

 

You are also occupying the whole PAGE_7000 by writing PAGE_7000 INTO FLASH_PAGE7000;

And then you try to show even more stuff into it although it is already full.

 

Library could -should- end up in NON_BANKED, unless you managed to fill up that area.

 

Also, if this is a S12 there are reserved registers plus the vector table starting at FF80, so don't allocate anything beyond that address unless it's the vector table itself.

0 Kudos
613 Views
CrasyCat
Specialist III

Hello

 

In case you use two non contiguous memory area to store the section NON_BANKED make sure to build your application and the ANSI library with option -OnB=b.

 

If you create your project using the wizard, the original .prm file contains following comment:

                           /* in case you want to use ROM_4000 here as well, make sure
                              that all files (incl. library files) are compiled with
                              the option: -OnB=b */
              INTO  ROM_C000/*, ROM_4000*/;

 This options makes sure the compiler does not attempt to replace a JSR with a BSR.

 

 Alternatively you can try moving the section NON_BANKED up in the list of sections to allocate into FLASH_PAGEC000,FLASH_PAGE7000

 

PLACEMENT
   NON_BANKED, /* runtime routines which must not be banked */
   _PRESTART, /* Used in HIWARE format: jump to _Startup at the code start */
   STARTUP, /* startup data structures */
   ROM_VAR, /* constant variables */
   STRINGS, /* string literals */
   VIRTUAL_TABLE_SEGMENT, /* C++ virtual table segment */
   PAGE_C000, PAGE_IRQ, COPY
                           INTO FLASH_PAGEC000,FLASH_PAGE7000;

    PAGE_7000              INTO  FLASH_PAGE7000;   

 

CrasyCat

612 Views
sebasira
Senior Contributor I

CrasyCat:

Well, that movement works... now the application compiles...

 

I'm working on a project that was already started when I came in. I guess it was created from wizard, but I'm not completly sure. The person who create this made some changes on the PRM, he hasn't much experience on PRM files, and truly, me neither... I don't have the comment you mentioned, I'll post the entire PRM so you can see if you can give me some advices.

 

 

 

Lundin:

First of all I don't fully understand:  

 

Zero page? What MCU are you using? S12 non-fixed flash is typically located at 8000 and C000 respectively, but on S12 the zero page is optimized for on-chip registers rather than user data, and is best kept that way.

I'm using HCS12, in ZERO PAGE I've got:

- Constants

- EEPROM writing routines

- ISRs (Interrup Service Routtines)

- FLASH writing routines

 

NOTE: By saying ZERO PAGE, I mean PAGE_C000 and PAGE_7000 (please read what's next)

 

As I said above it wasn't me how create that PRM file and again I don't fully understand them. If I'm not wrong PAGE_C000 and PAGE_7000 are both use as if there were ONE PAGE, the ZERO PAGE (and it's there were all the items above are stored). Is there any difference between them? If so, I didn't know about it

 

About:

 

You are also occupying the whole PAGE_7000 by writing PAGE_7000 INTO FLASH_PAGE7000;

And then you try to show even more stuff into it although it is already full.

 Again I don't know much about PRM. I thought that when I do that I was allocating the other stuff in the "space" that was not ocuppied by PAGE_7000. Let's say I use pragma to strore 100bytes in PAGE_7000 I guess that the other stuff was allocated in the space that's left from PAGE_7000

 

Here's my FULL PRM FILE:

 

NAMES

 
END

SECTIONS
  /*  RAM */  
   RAM = READ_WRITE 0x04000 TO 0x6FFF;
 /*banked FLASH ROM */
    FLASH_PAGE7000 = READ_ONLY 0x07000 TO 0x07FFF;
    FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
/* unbanked FLASH ROM */
    PAGE_30_part             = READ_ONLY  0x30B800 TO 0x30BFFF;
    PAGE_31                  = READ_ONLY  0x318000 TO 0x31BFFF;
    PAGE_32                  = READ_ONLY  0x328000 TO 0x32BFFF;
    PAGE_33                  = READ_ONLY  0x338000 TO 0x33BFFF;
    PAGE_34                  = READ_ONLY  0x348000 TO 0x34BFFF;
    PAGE_35_part             = READ_ONLY  0x35B002 TO 0x35BFFF;
    PAGE_36                  = READ_ONLY  0x368000 TO 0x36BFFF;
    PAGE_37                  = READ_ONLY  0x378000 TO 0x37BFFF;

    PAGE_38                  = READ_ONLY  0x388000 TO 0x38BFFF;   
    PAGE_39                  = READ_ONLY  0x398000 TO 0x39BFFF;  
    PAGE_3A                  = READ_ONLY  0x3A8000 TO 0x3ABFFF;  
    PAGE_3B                  = READ_ONLY  0x3B8000 TO 0x3BBFFF;  
    PAGE_3C                  = READ_ONLY  0x3C8000 TO 0x3CBFFF;  
    PAGE_3D                  = READ_ONLY  0x3D8000 TO 0x3DBFFF;

/*  PAGE_3E = READ_ONLY  0x3E8000 TO 0x3EBFFF;/* not used: equivalent to MY_ROM_1 */ 
 /* PAGE_3F = READ_ONLY  0x3F8000 TO 0x3FBFFF;/* not used: equivalent to MY_ROM_2 */ 


END
   
PLACEMENT
    NON_BANKED,
    _PRESTART,
    STARTUP,
    ROM_VAR,
    STRINGS,
    VIRTUAL_TABLE_SEGMENT,
    PAGE_C000,
    PAGE_IRQ,
    COPY                   INTO  FLASH_PAGEC000,FLASH_PAGE7000;   
   
    PAGE_7000     INTO  FLASH_PAGE7000;

  
  //CODIGO
    PAGE_30_CODE    INTO  PAGE_30_part;
    PAGE_31_CODE    INTO  PAGE_31;
    PAGE_32_CODE    INTO  PAGE_32;
    PAGE_33_CODE    INTO  PAGE_33;
    PAGE_34_CODE    INTO  PAGE_34;
    PAGE_35_CODE    INTO  PAGE_35_part;
    PAGE_36_CODE    INTO  PAGE_36;
    PAGE_37_CODE    INTO  PAGE_37;
    PAGE_38_CODE    INTO  PAGE_38;
    PAGE_39_CODE    INTO  PAGE_39;
    PAGE_3A_CODE    INTO  PAGE_3A;
    PAGE_3B_CODE    INTO  PAGE_3B;
    PAGE_3C_CODE    INTO  PAGE_3C;
    PAGE_3D_CODE    INTO  PAGE_3D;

  //CONSTANTES
    //PAGE_30_CONST   INTO  PAGE_30;
    PAGE_31_CONST   INTO  PAGE_31;
    PAGE_32_CONST   INTO  PAGE_32;
    PAGE_33_CONST   INTO  PAGE_33;
    PAGE_34_CONST   INTO  PAGE_34;
    PAGE_35_CONST   INTO  PAGE_35_part;
    PAGE_36_CONST   INTO  PAGE_36;
    PAGE_37_CONST   INTO  PAGE_37;
    PAGE_38_CONST   INTO  PAGE_38;
    PAGE_39_CONST   INTO  PAGE_39;
    PAGE_3A_CONST   INTO  PAGE_3A;
    PAGE_3B_CONST   INTO  PAGE_3B;
    PAGE_3C_CONST   INTO  PAGE_3C;
    PAGE_3D_CONST   INTO  PAGE_3D;
   
    PAGE_CONST      INTO  FLASH_PAGEC000,FLASH_PAGE7000;
 
    DEFAULT_ROM     INTO  PAGE_3C,PAGE_3D;
    DEFAULT_RAM     INTO  RAM;
                         
  
END


STACKSIZE 0x400

 

Anything.. I mean ANYTHING you notice in it please let me know... That's how I've been working for years and don't know why because it was that way when I start working.

 

Thanks!!!

 

 

0 Kudos
612 Views
CompilerGuru
NXP Employee
NXP Employee

The zero page for a S12 (S12X can be used differently) is from address 0x00 to 0xFF, so that's another topic. I call the flash area outside of the 0x??8000..0x??BFFF window non banked.

 

I guess lundin did get on that track because the error message when placing objects compiled for the zero page elsewhere looks very similar. But in this case crazycat is right.

The issue is when you list multiple segments in a placement clause on the right side, after the INTO:

 

 

NON_BANKED,...INTO FLASH_PAGEC000,FLASH_PAGE7000;

 

 

Then the linker starts to place objects from NON_BANKED into FLASH_PAGEC000 until that segment is full, and then the linker continues to place the remaining objects into FLASH_PAGE7000. When this segment switch happens, the distance in between two objects in NON_BANKED can become bigger as it was initially, and this change is not compatible with the -onb=b optimization.

 

In order to avoid this case, you can:

- when compiling without -onb=b, do not list multiple segments on the right side

- this issue only occurs in __near code, so banked code is not an issue, that segment list is safe.

- compile the non banked code with -onb=b

 

For this case it would be possible to recompile the ANSI lib with -onb=b. but it is much simpler not distribute NON_BANKED into multiple segments. For you own non banked code, add -onb=b to your project. 

The prm could then look like this:

 

PLACEMENT    NON_BANKED,PAGE_C000   INTO  FLASH_PAGEC000;    PAGE_7000     INTO  FLASH_PAGE7000;     _PRESTART,    STARTUP,    ROM_VAR,    STRINGS,    VIRTUAL_TABLE_SEGMENT,    PAGE_IRQ,    COPY                   INTO  FLASH_PAGEC000,FLASH_PAGE7000;        ...

(only changed parts, and I also placed PAGE_C000 into FLASH_PAGEC000 only, just because of the section name Smiley Happy.

 

Daniel

 

 

0 Kudos