#1797 [PIC16] --ivt-loc/crt0i conflicting with linker script

open
nobody
PIC16
5
2013-07-16
2011-06-17
No

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

Discussion

  • strobla

    strobla - 2011-08-06

    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

     
  • Diego Herranz

    Diego Herranz - 2011-10-03

    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.

     
  • Philipp Klaus Krause

    • Category: --> PIC16
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks