[sdcc-devel] [ sdcc-Bugs-3317892 ] [PIC16] --ivt-loc/crt0i conflicting with linker script

[SourceForge.net <no...@so...>]

Bugs item #3317892, was opened at 2011-06-17 15:31
Message generated for change (Comment added) made by diegoherranz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3317892&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pic16 target
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Diego Herranz (diegoherranz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PIC16] --ivt-loc/crt0i conflicting with linker script

Initial Comment:
Trying to compile code to use on a PIC16 with a bootloader placed on the lower 0x800 addresses.

$ sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Feb  3 2010) (UNIX)

Compiling with:
$ sdcc -mpic16 -p18f2550 --ivt-loc=0x800 --link="gplink -s mylinkerscript.lkr" main.c

Being mylinkerscript.lkr:
[...]
CODEPAGE   NAME=boot       START=0x0               END=0x7FF		PROTECTED
CODEPAGE   NAME=page       START=0x800               END=0x7FFF
CODEPAGE   NAME=idlocs     START=0x200000          END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000          END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE          END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000          END=0xF000FF       PROTECTED
[...]

Looking at main.lst, high priority interrupt vector has been placed at 0x808 address and low priority interrupt vector at 0x818 (as expected).

However, doing:
$ gpdasm -p18f2550 main.hex | head -8
000000:  ef1c  goto	0xa38
000002:  f005
000800:  b09e  btfsc	0x9e, 0, 0
000802:  efb0  goto	0x960
000804:  f004
000806:  0010  retfie	0
000808:  ef28  goto	0xa50
00080a:  f005

We can see that there is code placed at 0x000 address. I think this is because crt0i is already compiled and "_entry (void) __naked __interrupt 0" has been hard placed at 0x0000.

- Maybe crt0i should be recompiled when a non-default linker script is used
- Or, trying to avoid recompilation, ¿could "_entry (void) __naked __interrupt 0" be placed at ivt-loc (symbolic) and be finally resolved by linker (or something similar)? I don't even know if this is possible.

Thanks a lot for this great project




----------------------------------------------------------------------

>Comment By: Diego Herranz (diegoherranz)
Date: 2011-10-03 14:02

Message:
Sorry, I didn't see your comment on holidays. I've just come across it.

I don't have any problem with high and low isr's because my bootloader
remaps them to 0x808 and 0x818 and sdcc with option --ivt-loc=0x800 places
them at the correct addresses.

The problem comes with the other interrupt vector (reset vector). I would
like it to be placed at 0x800 (where my bootloader goes for normal
operation), but it's placed at 0x000 instead. 

Thanks for your help.

----------------------------------------------------------------------

Comment By: strobla (awsit)
Date: 2011-08-06 15:36

Message:
Dear Diego,

use the switch "--no-crt" and for your interrupt service routines use
something like:

/* Interrupt vectors */
#pragma code high_priority_isr 0x820
void high_priority_isr(void) __interrupt
{
}  

#pragma code low_priority_isr 0x2000
void low_priority_isr(void) __interrupt
{
}

=> irq adresses are only for example: you need to know, where your
bootloader remaps the irq entry addresses.

Hope this helps.
Regards, Strobl Anton



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3317892&group_id=599