Post by thread:[PIC]: Unusual linker characteristic

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

> 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

>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.