#632 No codepages for PIC 16F873 - no memory for ``.udata''

closed-fixed
5
2013-05-25
2003-11-11
No

I don't know if this is a gplink bug or a sdcc bug so I
will report it
both in gputils and in sdcc.

When you create a C program and the target is a 16f873
sdcc puts the user
data in the assembler file like this:

;--------------------------------------------------------
; udata
;--------------------------------------------------------
udata
; .area DSEG (DATA)
_INDF EQU 0x0000
_PCL EQU 0x0002
r0x22 res 1
r0x23 res 1
WSAVE EQU 0x007f

And then gplink tries to put it in a databank section
that is not
protected (see gp_cofflink_reloc_unassigned in
gpcofflink.c) but the
linker script for the 16f873 processor does not contain
a unprotected
databank section, it only contains sharebank sections.
So gplink fails
with this error:

message: using default linker script
"/usr/local/share/gputils/lkr/16f873.lkr"
error: no target memory available for section ".udata"

The only way to make gplink work in this case is to
change the 16f873
script from this:

-----------------------------------------------------------------------
// Sample linker command file for 16F873
// $Id: 16f873.lkr,v 1.4 2003/07/20 06:46:46
craigfranklin Exp $

LIBPATH .

CODEPAGE NAME=vectors START=0x0 END=0x4
PROTECTED
CODEPAGE NAME=page0 START=0x5 END=0x7FF
CODEPAGE NAME=page1 START=0x800 END=0xFFF
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=sfr0 START=0x0 END=0x1F
PROTECTED
DATABANK NAME=sfr1 START=0x80 END=0x9F
PROTECTED
DATABANK NAME=sfr2 START=0x100 END=0x10F
PROTECTED
DATABANK NAME=sfr3 START=0x180 END=0x18F
PROTECTED

SHAREBANK NAME=gpr0 START=0x20 END=0x7F
SHAREBANK NAME=gpr0 START=0x120 END=0x17F

SHAREBANK NAME=gpr1 START=0xA0 END=0xFF
SHAREBANK NAME=gpr1 START=0x1A0 END=0x1FF

SECTION NAME=STARTUP ROM=vectors // Reset and
interrupt vectors
SECTION NAME=PROG1 ROM=page0 // ROM code
space - page0
SECTION NAME=PROG2 ROM=page1 // ROM code
space - page1
SECTION NAME=IDLOCS ROM=.idlocs // ID locations
SECTION NAME=CONFIG ROM=.config //
Configuration bits location
SECTION NAME=DEEPROM ROM=eedata // Data EEPROM
-----------------------------------------------------------------------

To this:

--------------------------------------------------------------------
// Sample linker command file for 16F873
// $Id: 16f873.lkr,v 1.4 2003/07/20 06:46:46
craigfranklin Exp $

LIBPATH .

CODEPAGE NAME=vectors START=0x0 END=0x4
PROTECTED
CODEPAGE NAME=page0 START=0x5 END=0x7FF
CODEPAGE NAME=page1 START=0x800 END=0xFFF
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=sfr0 START=0x0 END=0x1F
PROTECTED
DATABANK NAME=sfr1 START=0x80 END=0x9F
PROTECTED
DATABANK NAME=sfr2 START=0x100 END=0x10F
PROTECTED
DATABANK NAME=sfr3 START=0x180 END=0x18F
PROTECTED

DATABANK NAME=gpr0 START=0x20 END=0x7F
DATABANK NAME=gpr1 START=0xA0 END=0xFF

SECTION NAME=STARTUP ROM=vectors // Reset and
interrupt vectors
SECTION NAME=PROG1 ROM=page0 // ROM code
space - page0
SECTION NAME=PROG2 ROM=page1 // ROM code
space - page1
SECTION NAME=IDLOCS ROM=.idlocs // ID locations
SECTION NAME=CONFIG ROM=.config //
Configuration bits location
SECTION NAME=DEEPROM ROM=eedata // Data EEPROM
--------------------------------------------------------------------------

I think this is the reason why some people in the sdcc
forums is
complaining about memory errors when compiling for some
PIC targets.
And I guess that the problem goes for some other PICs
that mirror their
data pages.

Discussion

  • Jaime Alberto Silva

    Logged In: YES
    user_id=60015

    This bug was rejected from gputils with the following
    explanation:

    Date: 2003-11-11 21:20
    Sender: craigfranklin
    Logged In: YES
    user_id=91596

    It appears that gplink is operating correctly. I ran a test
    case with mplink and got the same result.

    I also checked the linker script against device datasheet
    and it is also correct.

    It looks like the section type in SDCC should
    be "udata_shr"
    instead of "udata".

    The problem will have to be fixed in SDCC. Either a change
    for specific devices or a way for users to specify what type
    of section that program data will be placed in.

    I don't listen to the SDCC forum. Please forward my
    response, so everyone is informed. Thanks.

     
  • Vangelis Rokas

    Vangelis Rokas - 2004-01-08
    • milestone: --> fixed
    • assigned_to: nobody --> vrokas
    • status: open --> closed-fixed
     
  • Vangelis Rokas

    Vangelis Rokas - 2004-01-08

    Logged In: YES
    user_id=770505

    fixed in CVS.
    One can use command line option --udata-section-name to
    override default 'udata' name for the uninitialized section, i.e.:
    sdcc --udata-section-name=udata_shr

    will work fine for 16F873.

     
  • Jaime Alberto Silva

    Logged In: YES
    user_id=60015

    But what happens with PICs that can use both udata and
    udata_shr sections like the 16f877?. Will they be limited to
    only one type of data section?.

     

Log in to post a comment.