Searching \ for '[PIC]: Unusual linker characteristic' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Unusual linker characteristic'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Unusual linker characteristic'
2002\04\18@123248 by Alan B. Pearce

face picon face
I have been doing some puzzling over the MPLAB linker because it seems to
put code in strange places.

I get the following map output for my project when the last 0x100 bytes are
protected for use with the ICD.


                      Section Info
       Section       Type    Address   Location Size(Bytes)
     ---------  ---------  ---------  ---------  ---------
        .RESET       code   0x000000    program   0x000008
     .INTR_SVC       code   0x000004    program   0x000048
        .cinit    romdata   0x001800    program   0x000004
          .I2C       code   0x001802    program   0x0001c8
          .PWM       code   0x0018e6    program   0x000182
         .MAIN       code   0x0019a7    program   0x000138
         .FPAA       code   0x001a43    program   0x0000f2
        .START       code   0x001abc    program   0x000044
         .PORT       code   0x001ade    program   0x00002e
         .INTR       code   0x001af5    program   0x00000a
       .config       code   0x002007    program   0x000002
        .BANK2      udata   0x000020       data   0x00004a
        .TEMPW      udata   0x00006f       data   0x000001
         .REGS      udata   0x000071       data   0x00000d
    .udata_shr      udata   0x00007e       data   0x000001
        .BANK0      udata   0x0000a0       data   0x000015

                   Program Memory Usage
                    Start         End
                ---------   ---------
                 0x000000    0x000027
                 0x001800    0x001af9
                 0x002007    0x002007
 803 out of 8453 program addresses used, program memory utilization is 9%

I do not know where the ".cinit    romdata" is coming from. It is always
there, and if I unprotect the last 256 bytes then it becomes as follows

       Section       Type    Address   Location Size(Bytes)
     ---------  ---------  ---------  ---------  ---------
        .RESET       code   0x000000    program   0x000008
     .INTR_SVC       code   0x000004    program   0x000048
          .PWM       code   0x001800    program   0x000182
         .MAIN       code   0x0018c1    program   0x000138
         .FPAA       code   0x00195d    program   0x0000f2
        .START       code   0x0019d6    program   0x000044
         .INTR       code   0x0019f8    program   0x00000a
        .cinit    romdata   0x001f00    program   0x000004
          .I2C       code   0x001f02    program   0x0001c8
         .PORT       code   0x001fe6    program   0x00002e
       .config       code   0x002007    program   0x000002
        .BANK2      udata   0x000020       data   0x00004a
        .TEMPW      udata   0x00006f       data   0x000001
         .REGS      udata   0x000071       data   0x00000d
    .udata_shr      udata   0x00007e       data   0x000001

Note that the .cinit section has now moved, but the relocatable code still
starts at 0x1800.
If I now make the page 3 portion of the linker script a single line for the
whole rom page instead of 2 lines, one from 0x1800 to 0x1eff, and a second
one from 0x1f00 to 0x1fff, then I get the following output

       Section       Type    Address   Location Size(Bytes)
     ---------  ---------  ---------  ---------  ---------
        .RESET       code   0x000000    program   0x000008
     .INTR_SVC       code   0x000004    program   0x000048
        .cinit    romdata   0x000028    program   0x000004
          .I2C       code   0x00002a    program   0x0001c8
          .PWM       code   0x00010e    program   0x000182
         .MAIN       code   0x0001cf    program   0x000138
         .FPAA       code   0x00026b    program   0x0000f2
        .START       code   0x0002e4    program   0x000044
         .PORT       code   0x000306    program   0x00002e
         .INTR       code   0x00031d    program   0x00000a
       .config       code   0x002007    program   0x000002
        .BANK2      udata   0x000020       data   0x00004a
        .TEMPW      udata   0x00006f       data   0x000001
         .REGS      udata   0x000071       data   0x00000d
    .udata_shr      udata   0x00007e       data   0x000001

Note that the .cinit has now moved to immediately after the absolute code
interrupt routine, and there is no whopping hole in the code. The rom area
occupied by this section seems to get filled with a pair of retlw 0
instructions, and from the name of the section I assume it has something to
do with linking in C code, but I have no C code, and have definitely not
declared such a section called .cinit, nor do I use the type romdata.

I would like to try and figure this out if anyone has any ideas.

TIA
Alan

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\18@145146 by Olin Lathrop

face picon face
> I have been doing some puzzling over the MPLAB linker because it seems to
> put code in strange places.

Everything you showed looked perfectly normal.  I think the CINIT section is
something it automatically generates to hold the data for initialized RAM
locations.  It seems to always be there for me too, even though I never use
initialized RAM.  I tried several tricks once to get rid of it, but
eventually gave up.

The way the linker decided where to put your code also makes sense.  Too bad
you didn't show the linker control file.  I'm guessing it's very similar to
what I use (the names hint that maybe it IS what I use), which is to create
a separate section for each program memory page.  The linker tries to place
the largest block left into the smallest space that will hold it until all
blocks have been placed.  However, "hardwired" blocks go where you tell them
to go.  Since you blocked out the last 100h words of page 3, the remainder
of page 3 became the smallest space that would fit subsequent modules.
Since your code fits completely within one page, everything got put there
except the code at 0 and 4 which was hard wired to those locations.
Perfectly reasonable.

When you stopped splitting up page 3 the linker put everything in page 0,
which also makes sense.  Since the RESET and INTR_SVC were hard wired to
page 0, the remainder of page 0 became the smallest space to place the other
modules in.

Of course none of this should really matter.  If the code is written right
it should run no matter what page it ends up on.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\04\19@042947 by Alan B. Pearce

face picon face
>The way the linker decided where to put your code also makes sense.
>Too bad you didn't show the linker control file.  I'm guessing it's
>very similar to what I use (the names hint that maybe it IS what I use

Yes the code is built using your modular system, and I tried with both your
linker file, and the microchip supplied one.

>Of course none of this should really matter.  If the code is
>written right it should run no matter what page it ends up on.

Agreed, it just surprised me that it was putting it "up in the clouds" of
the address space, but your explanation makes sense. Thanks for the time to
describe the process. Initially I thought that whatever was causing the
.cinit was related to why the code was placed where it was.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...