Lpc2000

Hi,

I have a strange problem when using the library newlib-lpc_rel_4. I am
using the gcc downloaded from http://www.gnuarm.org. The problem is
the same whether I compile under cygwin or Linux. When using the makefile
that comes with the package, it builds the examples by directly
linking with all object files. These examples work on my hardware
without any problems. If I build the examples (specifically example
test10) by compiling test10.c and then linking with the library in
stead of directly with the object files used to create the library,
the example does not work. The test10 example sets some I/O pins to
output, and
prints some strings to the serial port using interrupt driven serial
I/O. The code linked to the library, sets up the I/O pins as expected,
but the serial comms does not work. There are no error messages when
linking either directly with the object files or with the library. 
The binary filesize of the output files are  26944 bytes when linking
against the library and 27840 when linking directly with the object
files. Any suggestions on where to look to see what is not being
included when linking with the library ?

Regards
  Anton Erasmus

At 07:58 AM 2/21/05 +0000, aj_erasmus wrote:
>The binary filesize of the output files are  26944 bytes when linking
>against the library and 27840 when linking directly with the object
>files. Any suggestions on where to look to see what is not being
>included when linking with the library ?

Anton, check the map file.  Is the newlib-lpc library getting linked in? 
Specifically the newlib-lpc routines for _write and _read. It's possible 
that your copy of newlib contains default stubs for these and they are 
getting linked in rather than the newlib-lpc routines.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

On 21 Feb 2005 at 8:58, Robert Adsett wrote:

> 
> At 07:58 AM 2/21/05 +0000, aj_erasmus wrote:
> >The binary filesize of the output files are  26944 bytes when linking
> >against the library and 27840 when linking directly with the object
> >files. Any suggestions on where to look to see what is not being
> >included when linking with the library ?
> 
> Anton, check the map file.  Is the newlib-lpc library getting linked
> in? Specifically the newlib-lpc routines for _write and _read. It's
> possible that your copy of newlib contains default stubs for these and
> they are getting linked in rather than the newlib-lpc routines.

I have investigated further and found the problem, but am unsure on how
to fix it. There 2 assembler files for containing some code related to interrupts. 
The 2 files are linked in when linking directly with all the files, but are not linked 
in from the library. All the other _read, _write etc modules are linked in from the 
library. The linker does not complain about any missing references when the 
assembly code is not linked in. I haved added the "used" attribute to the 
interrupt service routine, but the assembler calling this routine is still not linked 
in from the library.

Regards
   Anton Erasmus



-- 
A J Erasmus

At 07:13 PM 2/21/05 +0200, Anton Erasmus wrote:
>On 21 Feb 2005 at 8:58, Robert Adsett wrote:
> > At 07:58 AM 2/21/05 +0000, aj_erasmus wrote:
> > >The binary filesize of the output files are  26944 bytes when linking
> > >against the library and 27840 when linking directly with the object
> > >files. Any suggestions on where to look to see what is not being
> > >included when linking with the library ?
> >
> > Anton, check the map file.  Is the newlib-lpc library getting linked
> > in? Specifically the newlib-lpc routines for _write and _read. It's
> > possible that your copy of newlib contains default stubs for these and
> > they are getting linked in rather than the newlib-lpc routines.
>
>I have investigated further and found the problem, but am unsure on how
>to fix it. There 2 assembler files for containing some code related to 
>interrupts.
>The 2 files are linked in when linking directly with all the files, but 
>are not linked
>in from the library. All the other _read, _write etc modules are linked in 
>from the
>library. The linker does not complain about any missing references when the
>assembly code is not linked in. I haved added the "used" attribute to the
>interrupt service routine, but the assembler calling this routine is still 
>not linked
>in from the library.


Anton, I assume you mean interrupt_sup.s and uart0_ishell.s?

The former contains DisableInterrupts and RestoreInterrupts, both are 
called in the interrupt drive device driver so they certainly should be 
linked in.  The later contains Uart0InterruptShell which while not directly 
called is referred to by address in the setup and therefore should also end 
up being linked in.  The only thing that occurs to me is that those three 
references are being satisfied by something else.  Can you find them in the 
map file?

I suppose you could be missing the interrupt reference in the startup 
code.  The following line

         ldr     pc,[pc,#-0xFF0]         /* Vector via VIC               */

Should be in your exception vector table.  Even if that was missing though 
it I wouldn't expect it to make a difference to the link stage.  Interrupts 
wouldn't work but at least all items would be linked in.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III