Lpc2000

Hi,

linking directly to the object files of newlib-lpc (as it is done in the
example.mak) works perfectly, but linking to libnewlib-lpc.a doesn't
(the elf file size differs by a few bytes and the program does not run
correctly).

My linker command line:
arm-elf-ld -o myexample.elf crt0.o myexample.o -lnewlib-lpc -Tlpc210x.ld

Anything wrong here?

Andreas

At 09:48 AM 4/6/04 +0000, you wrote:
>linking directly to the object files of newlib-lpc (as it is done in the
>example.mak) works perfectly, but linking to libnewlib-lpc.a doesn't
>(the elf file size differs by a few bytes and the program does not run
>correctly).
>
>My linker command line:
>arm-elf-ld -o myexample.elf crt0.o myexample.o -lnewlib-lpc -Tlpc210x.ld

Might be link order.  I added the following to my load file when I started 
using the library.

         /*  Libraries to link against.                                  */
INPUT( -lc -lnewlib-lpc -lc -lgcc )


Try having ld dump a map file for the two links and compare, that should 
narrow down the possibilities as well.

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

Andreas told me about the "newlib-lpc" and i have tried to write a Tutorial.
So i have Compiled the newlib-lpc and wanted to create my own
prject-environment including a sample-Makefile.
Everything went very fine. I could build my own "Hello, World!" with the
first time I called this Makefile.
This "Hello, World!" should use the first UART, and print - uhm, i think you
can guess what :-)

But then, as I had downloaded the intel-hex-file to my LPC2106, nothing
seemed to happen.
I was wondering because all the samples delivered with newlib-lpc ran very
nice. So I copied my source file into the newlib-source-directory and added
it to the Makefile (example.mak, I think) like all the other example
sources.
Now my "Hello, World!" appeared after downloading to the processor...
So I did some thoughts about the things that happen in this example
Makefile. I found out, that everyone of these testX examples is linked
directly to the objectfiles of the lib. I tried to link again these
objectfiles, too, in my Makefile and I was wondering that the resulting
hexfile ran this time!
Up to now, I have not been able to resolve the Problem...but I found out,
that if I link the file _write_r.o directly, my "Hello, World!" string
appears on the serial port.
So, there is at least one problem with this objectfile.
I don't know if this is precise enough to solve our problem.

If you would need more information, I could give you access to my sample
project at

http://wiki.mikrocontroller.net/upload/f/f4/LPC2106-gcc-Demo_2.zip

Thanks in advance,
Patrick Dohmen...


"Robert Adsett" <subscriptions@...> schrieb im Newsbeitrag
news:5.1.0.14.0.20040406085709.17903360@......
> At 09:48 AM 4/6/04 +0000, you wrote:
> >linking directly to the object files of newlib-lpc (as it is done in the
> >example.mak) works perfectly, but linking to libnewlib-lpc.a doesn't
> >(the elf file size differs by a few bytes and the program does not run
> >correctly).
> >
> >My linker command line:
> >arm-elf-ld -o myexample.elf crt0.o myexample.o -lnewlib-lpc -Tlpc210x.ld
>
> Might be link order.  I added the following to my load file when I started
> using the library.
>
>          /*  Libraries to link against.
*/

> INPUT( -lc -lnewlib-lpc -lc -lgcc )
>
>
> Try having ld dump a map file for the two links and compare, that should
> narrow down the possibilities as well.
>
> 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
>
>
>
>
>

Patrick and I took this discussion off list so we could continue it w/o 
burden everyone with the details.  We appear to have found and fixed the 
source of the problem.

The upshot is the library he was using already had dummy newlib stubs in 
it.  So when linking they were taken in preference to the ones in 
libnewlib-lpc.a unless the replacements were linked in explicitly.

Two solutions:

The quick and dirty one is to remove the dummy stubs from the library 
(libc.a).  If you try this remember to backup the original first :)

The other solutions (the more correct one?) is to rebuild newlib without 
the pre-existing stubs (an option something like 
-DREENTRANT_SYSCALLS_PROVIDED if I remember correctly).  Check Bill 
Gatliff's article and the newlib documentation before proceeding.

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

Greetings,

After being around the block a few times with this
sticky issue, thought I'd pass along my findings.

Both OcdCommander and OcdLibRemote works with the
Wiggler hardware on the LPC210x, but you'll need to
disconnect nRST connection for the LPC210x target. 

Since nRST behaves differently on my EB40A eval
board(AT91R40008) and I move between these two
platforms, I installed a toggle switch on the Wiggler
box to enable/disable nRST control; Enable nRST for
the Atmel, and disable it for the LPC210x.

There was some discussion of this issue on Usenet ---
not clear what exactly the issue is, evidently there
are subtle differences. Anyhow, as long as it works
and we can have fun now.

Regards,

Johan.

--- In lpc2000@yahoogroups.com, Johan Forrer <jbforrer@y...> wrote:
> Greetings,
> 
> After being around the block a few times with this
> sticky issue, thought I'd pass along my findings.
> 
> Both OcdCommander and OcdLibRemote works with the
> Wiggler hardware on the LPC210x, but you'll need to
> disconnect nRST connection for the LPC210x target. 
> 
> Since nRST behaves differently on my EB40A eval
> board(AT91R40008) and I move between these two
> platforms, I installed a toggle switch on the Wiggler
> box to enable/disable nRST control; Enable nRST for
> the Atmel, and disable it for the LPC210x.
> 
> There was some discussion of this issue on Usenet ---
> not clear what exactly the issue is, evidently there
> are subtle differences. Anyhow, as long as it works
> and we can have fun now.

OCDCommander works fine for me with nRST connected to the Wiggler. I 
haven't tried OCDLib Remote with it yet.

Leon

Actually, I've found just the opposite.  I've has to disconnect
nRST when working with Atmel ARMs but have had no problem with
it being connected when working with the LPC.

-Bill Knight
R O SoftWare

On Thu, 15 Apr 2004 08:50:34 -0000, leon_heller wrote:

>--- In lpc2000@yahoogroups.com, Johan Forrer <jbforrer@y...> wrote:
>> Greetings,
>> 
>> After being around the block a few times with this
>> sticky issue, thought I'd pass along my findings.
>> 
>> Both OcdCommander and OcdLibRemote works with the
>> Wiggler hardware on the LPC210x, but you'll need to
>> disconnect nRST connection for the LPC210x target. 
>> 
>> Since nRST behaves differently on my EB40A eval
>> board(AT91R40008) and I move between these two
>> platforms, I installed a toggle switch on the Wiggler
>> box to enable/disable nRST control; Enable nRST for
>> the Atmel, and disable it for the LPC210x.
>> 
>> There was some discussion of this issue on Usenet ---
>> not clear what exactly the issue is, evidently there
>> are subtle differences. Anyhow, as long as it works
>> and we can have fun now.

>OCDCommander works fine for me with nRST connected to the Wiggler. I 
>haven't tried OCDLib Remote with it yet.

>Leon

--- In lpc2000@yahoogroups.com, "Bill Knight" <billk7670@c...> wrote:
> Actually, I've found just the opposite.  I've has to disconnect
> nRST when working with Atmel ARMs but have had no problem with
> it being connected when working with the LPC.
> 
> -Bill Knight
> R O SoftWare
>


Mine is OK with the old Atmel EB01 board with nRST connected.

Leon