Extraneous retlw files in mplabx

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Extraneous retlw files in mplabx

John Coppens
Hi all.

Anyone know why some 'retlw 0' might appear after linking in mplabx?
I normally use gpasm, but wanted to see if mpasm would generate the
same code. I was surprised that two of the retlw's appeared at the
start of the hex file, and probably others elsewhere, as the mpasm
generated code is 5 or 6 instructions larger.

Also, I can't seem to control the order of linking from the IDE, though
there was a reference this would be implemented by version 1.10

John

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Tamas Rudnai
Hi John,

Can you show the test code and the generated disassembly code?

Tamas


On 18 August 2012 10:35, John Coppens <[hidden email]> wrote:

> Hi all.
>
> Anyone know why some 'retlw 0' might appear after linking in mplabx?
> I normally use gpasm, but wanted to see if mpasm would generate the
> same code. I was surprised that two of the retlw's appeared at the
> start of the hex file, and probably others elsewhere, as the mpasm
> generated code is 5 or 6 instructions larger.
>
> Also, I can't seem to control the order of linking from the IDE, though
> there was a reference this would be implemented by version 1.10
>
> John
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Tamas Rudnai
I can see now what you mean. (see attached picture)

Tamas



On 18 August 2012 11:52, Tamas Rudnai <[hidden email]> wrote:

> Hi John,
>
> Can you show the test code and the generated disassembly code?
>
> Tamas
>
>
> On 18 August 2012 10:35, John Coppens <[hidden email]> wrote:
>
>> Hi all.
>>
>> Anyone know why some 'retlw 0' might appear after linking in mplabx?
>> I normally use gpasm, but wanted to see if mpasm would generate the
>> same code. I was surprised that two of the retlw's appeared at the
>> start of the hex file, and probably others elsewhere, as the mpasm
>> generated code is 5 or 6 instructions larger.
>>
>> Also, I can't seem to control the order of linking from the IDE, though
>> there was a reference this would be implemented by version 1.10
>>
>> John
>>
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>
>
>
> --
> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>


--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

Screen Shot 2012-08-18 at 12.52.16.PNG (48K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
In reply to this post by Tamas Rudnai
On Sat, 18 Aug 2012 11:52:06 -0700
Tamas Rudnai <[hidden email]> wrote:

> Hi John,
>
> Can you show the test code and the generated disassembly code?
>
> Tamas

Hi Tamas,

The code is somewhat difficult politically ;-), apart from the fact that
it's 8 modules linked together and quite a few lines...

The initial code generated (HEX) is:

:020000040000FA
:040000000034003494
:0C000400892B000000000000F000030E3B
...

The second line contains both retlw's, which are _not_ from my program.
I even did a search for 'retlw' in all .asm and .inc files I use. There
is none.

They seem to come from a separate module. I'm now suspecting this could
be some autogenerated code from a data reservation in the program area.
But they are not generated by gpasm/gplink. It seems mpasm interprets
something differently and generates those...

Bad news is that they get linked before the reset and interrupts
vectors, and I cannot find a way to change the order.

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Harold Hallikainen-2
In reply to this post by Tamas Rudnai
It looks to me like you're disassembling unprogrammed memory. The org
commands are leaving gaps of unprogrammed memory. When you disassemble it,
it shows whatever op-code corresponds to all ones.

Harold


> I can see now what you mean. (see attached picture)
>
> Tamas
>
>
>
> On 18 August 2012 11:52, Tamas Rudnai <[hidden email]> wrote:
>
>> Hi John,
>>
>> Can you show the test code and the generated disassembly code?
>>
>> Tamas
>>
>>
>> On 18 August 2012 10:35, John Coppens <[hidden email]> wrote:
>>
>>> Hi all.
>>>
>>> Anyone know why some 'retlw 0' might appear after linking in mplabx?
>>> I normally use gpasm, but wanted to see if mpasm would generate the
>>> same code. I was surprised that two of the retlw's appeared at the
>>> start of the hex file, and probably others elsewhere, as the mpasm
>>> generated code is 5 or 6 instructions larger.
>>>
>>> Also, I can't seem to control the order of linking from the IDE, though
>>> there was a reference this would be implemented by version 1.10
>>>
>>> John
>>>
>>> --
>>> http://www.piclist.com PIC/SX FAQ & list archive
>>> View/change your membership options at
>>> http://mailman.mit.edu/mailman/listinfo/piclist
>>>
>>
>>
>>
>> --
>> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
>> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
>> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>>
>
>
>
> --
> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Jan-Erik Söderholm
For me, this works (without getting extra RETLW's) *IF*
I make sure the "Build absolute mode" option is *checked*
in the project config dialog. If not, I get the same
result as Tamas.

But then, why have that option unchecked if you actualy
*are* building absolute mode code?

I also tried to simply change the two "org" into "code".
This time it didn't build at all with the "abs" option
checked, and unchecked I got the same two RETLW's...


Jan-Erik.





Harold Hallikainen wrote 2012-08-18 23:34:

> It looks to me like you're disassembling unprogrammed memory. The org
> commands are leaving gaps of unprogrammed memory. When you disassemble it,
> it shows whatever op-code corresponds to all ones.
>
> Harold
>
>
>> I can see now what you mean. (see attached picture)
>>
>> Tamas
>>
>>
>>
>> On 18 August 2012 11:52, Tamas Rudnai <[hidden email]> wrote:
>>
>>> Hi John,
>>>
>>> Can you show the test code and the generated disassembly code?
>>>
>>> Tamas
>>>
>>>
>>> On 18 August 2012 10:35, John Coppens <[hidden email]> wrote:
>>>
>>>> Hi all.
>>>>
>>>> Anyone know why some 'retlw 0' might appear after linking in mplabx?
>>>> I normally use gpasm, but wanted to see if mpasm would generate the
>>>> same code. I was surprised that two of the retlw's appeared at the
>>>> start of the hex file, and probably others elsewhere, as the mpasm
>>>> generated code is 5 or 6 instructions larger.
>>>>
>>>> Also, I can't seem to control the order of linking from the IDE, though
>>>> there was a reference this would be implemented by version 1.10
>>>>
>>>> John
>>>>
>>>> --
>>>> http://www.piclist.com PIC/SX FAQ & list archive
>>>> View/change your membership options at
>>>> http://mailman.mit.edu/mailman/listinfo/piclist
>>>>
>>>
>>>
>>>
>>> --
>>> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
>>> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
>>> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>>>
>>
>>
>>
>> --
>> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
>> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
>> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
In reply to this post by Harold Hallikainen-2
On Sat, 18 Aug 2012 14:34:00 -0700
"Harold Hallikainen" <[hidden email]> wrote:

> It looks to me like you're disassembling unprogrammed memory. The org
> commands are leaving gaps of unprogrammed memory. When you disassemble it,
> it shows whatever op-code corresponds to all ones.

Hello Harold.

The 3FFF instructions after the retlw's look like uninitialized memory
indeed, but the two 'retlw 0' appear from nowhere from MPLABX's linking.
In Tamas' case, they were linked at the end, in my case they're first,
shifting reset and interrupt vectors up.

>From the MPASM manual, it seems there are two sources for
auto-generated retlw's:

  - Replacing return pseudo ops in some processors,
  - dt (define table) will generate tables of retlw.

I don't think either is happening...

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
In reply to this post by Jan-Erik Söderholm
On Sat, 18 Aug 2012 23:56:50 +0200
Jan-Erik Soderholm <[hidden email]> wrote:

> For me, this works (without getting extra RETLW's) *IF*
> I make sure the "Build absolute mode" option is *checked*
> in the project config dialog. If not, I get the same
> result as Tamas.

Hallo Jan-Erik...

Strange: I never spent much time with that option, because the field
behind it is greyed out. It's almost unreadable, but it says (N/A)...
Any idea why that is?

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Tamas Rudnai
Looking at the map file, i can see that .cinit -- googling for it it seems
that is something to do with HiTech toolchain, and that linker puts
constant initialiser in there. Did Microchip switch to HiTech linker?

MPLINK 4.44, Linker
Linker Map File - Created Sat Aug 18 16:09:18 2012

                                 Section Info
                  Section       Type    Address   Location Size(Bytes)
                ---------  ---------  ---------  ---------  ---------
                      rst       code   0x000000    program   0x000006
                      int       code   0x000004    program   0x000002
                   .cinit    romdata   0x000005    program   0x000004



On 18 August 2012 15:56, Tamas Rudnai <[hidden email]> wrote:

> In relative mode the RETLWs are at the very beginning unless I define the
> address with 'code 0' whereas the two RETLWs goes to the end of the code...
>
> Tamas
>
>
> On 18 August 2012 15:39, John Coppens <[hidden email]> wrote:
>
>> On Sat, 18 Aug 2012 23:56:50 +0200
>> Jan-Erik Soderholm <[hidden email]> wrote:
>>
>> > For me, this works (without getting extra RETLW's) *IF*
>> > I make sure the "Build absolute mode" option is *checked*
>> > in the project config dialog. If not, I get the same
>> > result as Tamas.
>>
>> Hallo Jan-Erik...
>>
>> Strange: I never spent much time with that option, because the field
>> behind it is greyed out. It's almost unreadable, but it says (N/A)...
>> Any idea why that is?
>>
>> John
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>
>
>
> --
> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>



--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Tamas Rudnai
Sorry guys for the spam, speaking too soon, it is not a new linker nor the
MplabX. I have found the same question discussed here in piclist in 2002,
and even Olin could not suppress generating this .cinit section. As per
Olin we should not worry about this too much:

http://www.piclist.com/techref/postbot.asp?by=thread&id=Re%3A+%5BPIC%5D%3A+Unusual+linker+characteristic&w=body&tgt=_top

Tamas

On 18 August 2012 16:21, Tamas Rudnai <[hidden email]> wrote:

> Looking at the map file, i can see that .cinit -- googling for it it seems
> that is something to do with HiTech toolchain, and that linker puts
> constant initialiser in there. Did Microchip switch to HiTech linker?
>
> MPLINK 4.44, Linker
> Linker Map File - Created Sat Aug 18 16:09:18 2012
>
>                                  Section Info
>                   Section       Type    Address   Location Size(Bytes)
>                 ---------  ---------  ---------  ---------  ---------
>                       rst       code   0x000000    program   0x000006
>                       int       code   0x000004    program   0x000002
>                    .cinit    romdata   0x000005    program   0x000004
>
>
>
> On 18 August 2012 15:56, Tamas Rudnai <[hidden email]> wrote:
>
>> In relative mode the RETLWs are at the very beginning unless I define the
>> address with 'code 0' whereas the two RETLWs goes to the end of the code...
>>
>> Tamas
>>
>>
>> On 18 August 2012 15:39, John Coppens <[hidden email]> wrote:
>>
>>> On Sat, 18 Aug 2012 23:56:50 +0200
>>> Jan-Erik Soderholm <[hidden email]> wrote:
>>>
>>> > For me, this works (without getting extra RETLW's) *IF*
>>> > I make sure the "Build absolute mode" option is *checked*
>>> > in the project config dialog. If not, I get the same
>>> > result as Tamas.
>>>
>>> Hallo Jan-Erik...
>>>
>>> Strange: I never spent much time with that option, because the field
>>> behind it is greyed out. It's almost unreadable, but it says (N/A)...
>>> Any idea why that is?
>>>
>>> John
>>> --
>>> http://www.piclist.com PIC/SX FAQ & list archive
>>> View/change your membership options at
>>> http://mailman.mit.edu/mailman/listinfo/piclist
>>>
>>
>>
>>
>> --
>> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
>> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
>> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>>
>
>
>
> --
> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>



--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
On Sat, 18 Aug 2012 16:31:02 -0700
Tamas Rudnai <[hidden email]> wrote:

> Sorry guys for the spam, speaking too soon, it is not a new linker nor the
> MplabX. I have found the same question discussed here in piclist in 2002,
> and even Olin could not suppress generating this .cinit section. As per
> Olin we should not worry about this too much:
>
> http://www.piclist.com/techref/postbot.asp?by=thread&id=Re%3A+%5BPIC%5D%3A+Unusual+linker+characteristic&w=body&tgt=_top

Yes, somewhere I found a link from Microchip to the manual of the gcc
chain 'for further reading'.

Jan-Erik seems to have found a way to eliminate the section in absolute
mode, but I haven't found a way yet to switch that. Probably because I
have code/udata sections in the program, it will disable that switch
automatically.

Anyway, thanks for the reference to Olin and Alan's comments... I'll
edit the .lkr and try to get those extra instructions to move up.

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Jan-Erik Söderholm


John Coppens wrote 2012-08-19 02:19:

> On Sat, 18 Aug 2012 16:31:02 -0700
> Tamas Rudnai <[hidden email]> wrote:
>
>> Sorry guys for the spam, speaking too soon, it is not a new linker nor the
>> MplabX. I have found the same question discussed here in piclist in 2002,
>> and even Olin could not suppress generating this .cinit section. As per
>> Olin we should not worry about this too much:
>>
>> http://www.piclist.com/techref/postbot.asp?by=thread&id=Re%3A+%5BPIC%5D%3A+Unusual+linker+characteristic&w=body&tgt=_top
>
> Yes, somewhere I found a link from Microchip to the manual of the gcc
> chain 'for further reading'.
>
> Jan-Erik seems to have found a way to eliminate the section in absolute
> mode, but I haven't found a way yet to switch that. Probably because I
> have code/udata sections in the program, it will disable that switch
> automatically.

Yes, I was only testing the short abs-only code that Tamas posted... :-)

B.t.w, there is no reason to mix "org" and "code" as far as
I know.

Jan-Erik.



>
> Anyway, thanks for the reference to Olin and Alan's comments... I'll
> edit the .lkr and try to get those extra instructions to move up.
>
> John
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: Extraneous retlw files in mplabx

Alan Pearce - UKRI STFC
In reply to this post by Harold Hallikainen-2
> It looks to me like you're disassembling unprogrammed memory. The org
> commands are leaving gaps of unprogrammed memory. When you disassemble
> it, it shows whatever op-code corresponds to all ones.

That disassembles to the ADDLW 0xFF that you see following the highlighted lines in the picture. Not sure what opcode RETLW 0 is, bit I get the impression it is being used as a filler by the linker to cause some sort of crash if the code goes AWOL.

> > I can see now what you mean. (see attached picture)
> >
> > Tamas



--
Scanned by iCritical.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: Extraneous retlw files in mplabx

Alan Pearce - UKRI STFC
In reply to this post by Tamas Rudnai
> Looking at the map file, i can see that .cinit -- googling for it it
> seems that is something to do with HiTech toolchain, and that linker
> puts constant initialiser in there. Did Microchip switch to HiTech
> linker?
>
> MPLINK 4.44, Linker
> Linker Map File - Created Sat Aug 18 16:09:18 2012
>
>                                  Section Info
>                   Section       Type    Address   Location Size(Bytes)
>                 ---------  ---------  ---------  ---------  ---------
>                       rst       code   0x000000    program   0x000006
>                       int       code   0x000004    program   0x000002
>                    .cinit    romdata   0x000005    program   0x000004

Well, AIUI XC8 is the Hi-Tech compiler, so I would guess it uses the Hi-Tech linker ...


--
Scanned by iCritical.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: Extraneous retlw files in mplabx

Alan Pearce - UKRI STFC
In reply to this post by John Coppens
> Anyway, thanks for the reference to Olin and Alan's comments... I'll
> edit the .lkr and try to get those extra instructions to move up.

Oh my goodness, that photo has been around a while!!!


--
Scanned by iCritical.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Isaac Marino Bavaresco
In reply to this post by Alan Pearce - UKRI STFC
The ".cinit" section, as somebody already posted, is generated
automatically by the compiler to be used as a template to initialize all
the compile-time initialized variables.
The initialization code reads this table and copies the values to their
in-RAM locations.

Now I'm trusting my memory, but if I remember it right the table is
organized as a series of chunks with starting RAM address, length and
payload. At the very beginning of the table there is a long integer with
the number of chunks that follow.

Thus, it makes sense that a program that uses no compile-time
initialized variables end with four bytes equal to zero in the ".cinit"
section, it is the number of chunks of initialization data present.
That long must be there because usually the initialization code is
always linked, irrespectively if the program has initialized variables
or not.


Isaac



Em 19/8/2012 08:03, [hidden email] escreveu:

>> It looks to me like you're disassembling unprogrammed memory. The org
>> commands are leaving gaps of unprogrammed memory. When you disassemble
>> it, it shows whatever op-code corresponds to all ones.
> That disassembles to the ADDLW 0xFF that you see following the highlighted lines in the picture. Not sure what opcode RETLW 0 is, bit I get the impression it is being used as a filler by the linker to cause some sort of crash if the code goes AWOL.
>
>>> I can see now what you mean. (see attached picture)
>>>
>>> Tamas
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

Nicola Perotto
In reply to this post by Tamas Rudnai
If this poses problems you can use this in linker file
CODEPAGE   NAME=.cinit  START=0x2040   END=0x204F
The address can be where you want and where doesn't disturb!
If I remember correctly can be also out of real memory space.

      Nicola


On 18/08/2012 23:21, Tamas Rudnai wrote:

> Looking at the map file, i can see that .cinit -- googling for it it seems
> that is something to do with HiTech toolchain, and that linker puts
> constant initialiser in there. Did Microchip switch to HiTech linker?
>
> MPLINK 4.44, Linker
> Linker Map File - Created Sat Aug 18 16:09:18 2012
>
>                                  Section Info
>                   Section       Type    Address   Location Size(Bytes)
>                 ---------  ---------  ---------  ---------  ---------
>                       rst       code   0x000000    program   0x000006
>                       int       code   0x000004    program   0x000002
>                    .cinit    romdata   0x000005    program   0x000004
>
>
>
> On 18 August 2012 15:56, Tamas Rudnai <[hidden email]> wrote:
>
>> In relative mode the RETLWs are at the very beginning unless I define the
>> address with 'code 0' whereas the two RETLWs goes to the end of the code...
>>
>> Tamas
>>
>>
>> On 18 August 2012 15:39, John Coppens <[hidden email]> wrote:
>>
>>> On Sat, 18 Aug 2012 23:56:50 +0200
>>> Jan-Erik Soderholm <[hidden email]> wrote:
>>>
>>>> For me, this works (without getting extra RETLW's) *IF*
>>>> I make sure the "Build absolute mode" option is *checked*
>>>> in the project config dialog. If not, I get the same
>>>> result as Tamas.
>>> Hallo Jan-Erik...
>>>
>>> Strange: I never spent much time with that option, because the field
>>> behind it is greyed out. It's almost unreadable, but it says (N/A)...
>>> Any idea why that is?
>>>
>>> John
>>> --
>>> http://www.piclist.com PIC/SX FAQ & list archive
>>> View/change your membership options at
>>> http://mailman.mit.edu/mailman/listinfo/piclist
>>>
>>
>>
>> --
>> int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
>> printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
>> q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
>>
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
In reply to this post by Jan-Erik Söderholm
On Sun, 19 Aug 2012 11:57:47 +0200
Jan-Erik Soderholm <[hidden email]> wrote:

> B.t.w, there is no reason to mix "org" and "code" as far as
> I know.

Jan-Erik,

I don't have any org's in my code anymore. I now made sections in
the .lkr file to try and get the reset and interrupt code into their
places, but have not been able to do so:

CODEPAGE   NAME=.reset    START=0x0      END=0x3
CODEPAGE   NAME=.intserv  START=0x4      END=0xff
CODEPAGE   NAME=page0     START=0x100    END=0x7FF
CODEPAGE   NAME=page1     START=0x800    END=0xFFF

The sections in the program have 'code' like this:

page0           code

        (non-cricitical code)

.reset          code

        (code which has to be at 0)

.intserv code

        (code which has to be at 4)


The .reset code is replaced by the retlw's, and gets shifted to 0x6F
(after the .intserv code)!

I'm getting quite frustrated with mplabx too - I can't find an
option to request a map from the linker, and if I add -m test.map to
the linker options, it gets added *twice* to the mplink command line,
causing an error.

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
In reply to this post by Isaac Marino Bavaresco
On Sun, 19 Aug 2012 10:01:34 -0300
Isaac Marino Bavaresco <[hidden email]> wrote:

> Thus, it makes sense that a program that uses no compile-time
> initialized variables end with four bytes equal to zero in the ".cinit"
> section, it is the number of chunks of initialization data present.
> That long must be there because usually the initialization code is
> always linked, irrespectively if the program has initialized variables
> or not.

Hello Isaac,

The block contains only two retlw's, so they represent only a 16-bit
value if taken token together:

000000:  3400  retlw    0      
000001:  3400  retlw    0

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Extraneous retlw files in mplabx

John Coppens
In reply to this post by Jan-Erik Söderholm
On Sun, 19 Aug 2012 11:57:47 +0200
Jan-Erik Soderholm <[hidden email]> wrote:

> Yes, I was only testing the short abs-only code that Tamas posted... :-)

The thread is getting confusing, and I am even more confused. I did some
more tests, based on several suggestions and some between-the-lines:

I have this .lkr script (note the addresses for .cinit, and resetvec. For some
reason the addresses are interchanged)

CODEPAGE   NAME=resetvec  START=0x0      END=0x3
CODEPAGE   NAME=intserv   START=0x4      END=0xff
CODEPAGE   NAME=page0     START=0x100    END=0x7FF
CODEPAGE   NAME=page1     START=0x800    END=0xDFF
CODEPAGE   NAME=.cinit    START=0xE00    END=0xE0F

CODEPAGE   NAME=.idlocs  START=0x2000   END=0x2003   PROTECTED
CODEPAGE   NAME=.config  START=0x2007   END=0x2007   PROTECTED
CODEPAGE   NAME=eedata   START=0x2100   END=0x217F   PROTECTED

DATABANK   NAME=gpr0     START=0x20     END=0x6F

SHAREBANK  NAME=shr1     START=0x70     END=0x7F

...

The generated map:

                                 Section Info    
                  Section       Type    Address   Location Size(Bytes)
                ---------  ---------  ---------  ---------  ---------
                   .cinit    romdata   0x000000    program   0x000004
                  intserv       code   0x000004    program   0x0000d6
                    page0       code   0x000800    program   0x000918
                 resetvec       code   0x000e00    program   0x000008
.config_2007_BUILD/DEFAULT/PRODUCTION/MAIN.O       code   0x002007  program   0x000002
                     gpr0      udata   0x000020       data   0x00002a
                     shr1      udata   0x000070       data   0x000002
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
12