Re: Problem with gplink/gpasm and UDATA

A.J. Green,PEM wrote:
> Hello,
> 
> Here at Cambridge University Engineering Department we are big users of 
> open-source software.  As such I am looking at setting up a PIC 
> development environment using anjuta, gputils and sdcc.
> 
> At the moment I am struggling with gplink & gpasm.  I can't seem to get 
> gplink to link any object file that was compiled from an asm file with a 
> non-absolute UDATA section.  If I include an absolute memory location 
> (as in sec_name UDATA 0x20 instead of just sec-name UDATA) then 
> everything works fine.
> 
> I expect I am missing some fundamental point but I cannot for the life 
> of me work out why this doesn't work as I am fairly sure that the 
> location part is optional.
> 
> I'm using gputils v0.13.2 which is installed in /home/ajg72/picdev 
> (rather than /usr/local) and I have /home/ajg72/picdev/bin in my $PATH.
> 
> I am using the following commandlines:
> gpasm -c simple.asm
> gplink simple.o
> 
> simple.asm looks like this:
> ;-----------------------------------
>     list    p=16f873
>     radix dec
>     include "p16f873.inc"
>     __config 0x3fff
> 
>     
> data_sec    udata
> fred    res    1
> 
> 
> STARTUP    code
> 
> start    nop
>     goto    start
> 
>     end
> ;------------------------------------
> 
> gpasm reports no errors, warnings or messages but gplink outputs:
> message: using default linker script 
> "/home/ajg72/picdev//share/gputils/lkr/16f873.lkr"
> error: linker script has no definition that matches the type of section 
> "data_sec"
> 
> 
> thanks in advance for your help,
> Anthony Green - [email protected]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 

Hello Anthony,

I've had a little play with assembling the code, and reckon the problem 
lies with the (default) linker script, which fails to provide a suitable 
location for it to deposit the UDATA memory; nothing wrong with your 
code!  Putting the following into 16f873.lkr and 'gplink -s 16f873.lkr 
simple.o'ing allowed it to link without warnings here, although I'm 
afraid I haven't tried simulating.

---
// Sample linker command file for 16F873
// $Id: 16f873.lkr,v 1.8 2005/03/24 04:17:17 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=0x6F
DATABANK   NAME=gpr1     START=0xA0     END=0xEF
DATABANK   NAME=gpr2     START=0x110    END=0x16F
DATABANK   NAME=gpr3     START=0x190    END=0x1EF

SHAREBANK  NAME=gprnobank START=0x70    END=0x7F
SHAREBANK  NAME=gprnobank START=0xF0    END=0xFF
SHAREBANK  NAME=gprnobank START=0x170   END=0x17F
SHAREBANK  NAME=gprnobank START=0x1F0   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
---

Hope that this cures the problem, I'm really glad to hear that there is 
interest in the department for using this type of toolchain!

Regards,
Tim Gale