#632 No codepages for PIC 16F873 - no memory for ``.udata''
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.
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.
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.
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?.