Discussion:
NUTTX running in Red Suite Version 3
(too old to reply)
Nai
2010-08-10 16:38:37 UTC
Permalink
Hello,
I'm trying to compile Nuttx for the LPC3131 in Red Suite 3 IDE with no success. Is this because of the GCC version 4.2.4 used in Buildroot is different from the GCC used on Red Suite?
Gregory N
2010-08-10 17:34:03 UTC
Permalink
Post by Nai
I'm trying to compile Nuttx for the LPC3131 in Red Suite 3 IDE with
no success. Is this because of the GCC version 4.2.4 used in
Buildroot is different from the GCC used on Red Suite?
It looks like Red Suite is a version of Eclipse w/GNU tools tuned to support NXP products. Is that right?

I would not think that there would be any major incompatibilities between the GNU toolchains. But I would have to see the errors you are getting before I could give you any advice. Can you post the errors?

On probable issue is the Buildroot is a native Linux or Cygwin toolchain. Most likely, the GNU tools in Red Suite are Windows native tools. Look at configs/ea3131/README.txt in the section Youner "GNU Toolchain Options". You might try setting CONFIG_LPC3131_CODESOURCERYW in you .config file. You may need to make addition customizations to the top-level Make.defs file.

There are other complexities for using an IDE to build NuttX. There is some discussion of this in configs/ea3131/README.txt under the heading "IDEs"

Greg
Nai
2010-08-17 19:27:16 UTC
Permalink
Hi Greg,
Thanks for your advice. I decided to drop the Red Suite IDE and use an
open source IDE - Yagarto and Eclipse IDE.

Here is the steps I took:

Installed Yagarto tool chain.

Installed Eclipse Helios

Installed GNU ARM Eclipse Plug-in. GNU ARM Eclipse Plug-in managed all
the build and linking inside Eclipse. I'm don't know anything about
make files and linking script, so I use this plug-in.

I tried to build the EA3131 Board with only modules that I need.

I followed your advice by doing all the steps in
configs/ea3131/README.txt under the heading "IDEs"

With your help, I was able to build all the .c and .s files. Now I run
into library and linking problem. Here are the errors. Hope you can
help me out.




Description

Resource

Path

first defined here

Pulser_Plus_Nuttx_Yagarto

first defined here

Pulser_Plus_Nuttx_Yagarto

first defined here

lib_getopt.c

/Pulser_Plus_Nuttx_Yagarto/lib

make: *** [Pulser_Plus_Nuttx_Yagarto.elf] Error 1

Pulser_Plus_Nuttx_Yagarto

more undefined references to `IS_ALTFORM' follow

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

multiple definition of `getopt'

Pulser_Plus_Nuttx_Yagarto

multiple definition of `optind'

Pulser_Plus_Nuttx_Yagarto

multiple definition of `optopt'

Pulser_Plus_Nuttx_Yagarto

Pulser_Plus_Nuttx_Yagarto.elf section `.data' will not fit in region
`isram'

Pulser_Plus_Nuttx_Yagarto

Pulser_Plus_Nuttx_Yagarto.elf: warning: sh_link not set for section
`.ARM.exidx'

Pulser_Plus_Nuttx_Yagarto

region `isram' overflowed by 20840 bytes

Pulser_Plus_Nuttx_Yagarto

undefined reference to `devnull_register'

up_initialize.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/common

undefined reference to `IS_ALTFORM'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

undefined reference to `IS_ALTFORM'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

undefined reference to `IS_ALTFORM'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

undefined reference to `IS_ALTFORM'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

undefined reference to `IS_ALTFORM'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

undefined reference to `lowconsole_init'

up_initialize.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/common

undefined reference to `mkfatfs'

up_usbstrg.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/board

undefined reference to `ramdisk_register'

up_usbstrg.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/board

WARNINGS

'lib_dtoa' defined but not used

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

#warning "Not implemented"

lpc313x_irq.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/chip

#warning "timer_getoverrun not Implemented"

timer_getoverrun.c

/Pulser_Plus_Nuttx_Yagarto/sched

assignment discards qualifiers from pointer target type

lpc313x_i2c.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/chip

assignment makes pointer from integer without a cast

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

implicit declaration of function '__dtoa'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

implicit declaration of function 'IS_ALTFORM'

lib_libdtoa.c

/Pulser_Plus_Nuttx_Yagarto/lib

implicit declaration of function 'ramdisk_register'

up_usbstrg.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/board

no return statement in function returning non-void

lpc313x_i2c.c

/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/chip

too many arguments for format

barrier.c

/Pulser_Plus_Nuttx_Yagarto/examples/ostest

too many arguments for format

barrier.c

/Pulser_Plus_Nuttx_Yagarto/examples/ostest

too many arguments for format

mqueue.c

/Pulser_Plus_Nuttx_Yagarto/examples/ostest
Post by Gregory N
Post by Nai
I'm trying to compile Nuttx for the LPC3131 in Red Suite 3 IDE with
no success. Is this because of the GCC version 4.2.4 used in
Buildroot is different from the GCC used on Red Suite?
It looks like Red Suite is a version of Eclipse w/GNU tools tuned to
support NXP products. Is that right?
Post by Gregory N
I would not think that there would be any major incompatibilities
between the GNU toolchains. But I would have to see the errors you are
getting before I could give you any advice. Can you post the errors?
Post by Gregory N
On probable issue is the Buildroot is a native Linux or Cygwin
toolchain. Most likely, the GNU tools in Red Suite are Windows native
tools. Look at configs/ea3131/README.txt in the section Youner "GNU
Toolchain Options". You might try setting CONFIG_LPC3131_CODESOURCERYW
in you .config file. You may need to make addition customizations to the
top-level Make.defs file.
Post by Gregory N
There are other complexities for using an IDE to build NuttX. There is
some discussion of this in configs/ea3131/README.txt under the heading
"IDEs"
Post by Gregory N
Greg
Gregory Nutt
2010-08-17 21:21:09 UTC
Permalink
Hi, Nai,
... With your help, I was able to build all the .c and .s files. ...
I am glad to see that you are making progress!
... Now I run into library and linking problem.  Here are the errors.
Hope you can help me out.
I'll try.
first defined here     Pulser_Plus_Nuttx_Yagarto
Some errors like this make no sense to me.  Perhaps the error log was mangled by
Yahoo! groups?  I'll only respond to the errors that make sense to me
  
 more undefined references to `IS_ALTFORM' follow   
lib_libdtoa.c    /Pulser_Plus_Nuttx_Yagarto/lib
I think I understand this one.  This is because the file lib_libdtoa.c is not
compiled directly.  Rather, it is included within lib_vsprintf.c.  I did this in
this odd way because if you enable this floating point support, there are subtle
changes in the licensing because dtoa() is under the old BSD license.
lib_libvsprintf.c:192:#  include "lib_libdtoa.c"


What you need to do is to remove the file lib_libdtoa.c from your project.
 
multiple definition of `getopt' ...
multiple definition of `optind' ...
multiple definition of `optopt' ...
My guess is that you are trying to link the NuttX libc with the some other
libc.  Make sure that you have -nostdlibs in your linker flags.  These are
defined in only one place in NuttX:  lib/lib_getopt.c.
Pulser_Plus_Nuttx_Yagarto.elf section `.data' will not fit in region `isram'
...
This is some problem in your linker script.  What linker script are you using? 
The normal ld.script file for the ea3131?  The size of isram is 192Kb.  This
seems to be saying that the size of your image is larger than 192Kb.

By default, the ea3131 examples execute out of internal SRAM.  If you are
building something larger, you will probably have to change the ld.script file
so that the program linked for FLASH and use the lpc313x bootloader to save the
program to FLASH.
Pulser_Plus_Nuttx_Yagarto.elf: warning: sh_link not set for section
`.ARM.exidx' ...
This is not an error.  Some toolchains generate this. Google for it, lots of
people see it and it is apparently not harmful.  But I don't see it with
the toolchain that I use.
 
undefined reference to `devnull_register'    up_initialize.c
Defined in the file drivers/dev_null.c.  Either you need to add dev_null.c in
your project or remove the call from up_initialize.c.
undefined reference to `lowconsole_init'    up_initialize.c
Similar comments.  lowconsole_init is defined in drivers/serial/lowconsole.c
undefined reference to `mkfatfs'            up_usbstrg.c
Defined in fs/fat/fs_mkfatfs.c
undefined reference to `ramdisk_register'    up_usbstrg.c
Defined in drivers/ramdisk.c
no return statement in function returning non-void    lpc313x_i2c.c
This is fixed in CVS.

Greg
Nai
2010-08-18 18:44:10 UTC
Permalink
Hi Greg,

My project involve using lpc3130 to generate pulses. I design my board
using lpc3130 with no external memmory. I run my code from the 96k of
SRAM. Would you mind show me how to use a strip down barebone version
of Nuttx that will fit in a small memory area. All I need is the RTOS
without file system, graphics, net, huge libraries (just some useful
popular one like printf).


I tried to following from your previous suggestion:

Removed lib_libdtoa.c

Added -nostdlibs to my linker flag

Used the ld.script from configs/ea3131/usbserial

Now I'm running in to more errors as follow:

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_releasefiles.c:80:
undefined reference to `files_releaselist'

./sched/sched_setupidlefiles.o: In function `sched_setupidlefiles':

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setupidlefiles.c:88:
undefined reference to `files_alloclist'

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setupidlefiles.c:110:
undefined reference to `open'

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setupidlefiles.c:113:
undefined reference to `dup2'

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setupidlefiles.c:114:
undefined reference to `dup2'

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setupidlefiles.c:118:
undefined reference to `close'

./sched/sched_setuppthreadfiles.o: In function
`sched_setuppthreadfiles':

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setuppthreadfiles.c:86:
undefined reference to `files_addreflist'

./sched/sched_setuptaskfiles.o: In function `sched_setuptaskfiles':

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setuptaskfiles.c:105:
undefined reference to `files_alloclist'

C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_setuptaskfiles.c:144:
undefined reference to `files_dup'

./lib/lib_fclose.o: In function `fclose':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fclose.c:59: undefined
reference to `close'

./lib/lib_fgets.o: In function `_lib_rawgetc':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fgets.c:100: undefined
reference to `read'

./lib/lib_fgets.o: In function `_lib_consoleputc':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fgets.c:117: undefined
reference to `write'

./lib/lib_fgets.o: In function `_lib_consoleputs':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fgets.c:128: undefined
reference to `write'

./lib/lib_fopen.o: In function `lib_fdopen':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fopen.c:158: undefined
reference to `inode_checkflags'

./lib/lib_fopen.o: In function `fopen':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fopen.c:242: undefined
reference to `open'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fopen.c:247: undefined
reference to `close'

./lib/lib_fread.o: In function `fread':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fread.c:96: undefined
reference to `__aeabi_uidiv'

./lib/lib_fseek.o: In function `fseek':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fseek.c:135: undefined
reference to `lseek'

./lib/lib_ftell.o: In function `ftell':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_ftell.c:118: undefined
reference to `lseek'

./lib/lib_fwrite.o: In function `fwrite':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fwrite.c:96: undefined
reference to `__aeabi_uidiv'

./lib/lib_libfflush.o: In function `lib_fflush':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_libfflush.c:151: undefined
reference to `write'

./lib/lib_libfread.o: In function `lib_fread':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_libfread.c:176: undefined
reference to `read'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_libfread.c:219: undefined
reference to `read'

./lib/lib_libvsprintf.o: In function `llutodec':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_libvsprintf.c:762: undefined
reference to `__aeabi_uldivmod'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_libvsprintf.c:763: undefined
reference to `__aeabi_uldivmod'

./lib/lib_qsort.o: In function `qsort':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_qsort.c:227: undefined
reference to `__aeabi_uidiv'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_qsort.c:234: undefined
reference to `__aeabi_uidiv'

./lib/lib_rand.o: In function `nrand':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rand.c:158: undefined
reference to `__aeabi_ui2d'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rand.c:158: undefined
reference to `__aeabi_dmul'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rand.c:158: undefined
reference to `__aeabi_d2uiz'

./lib/lib_rand.o: In function `frand1':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rand.c:175: undefined
reference to `__aeabi_ui2d'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rand.c:175: undefined
reference to `__aeabi_ddiv'

./lib/lib_rawinstream.o: In function `rawinstream_getc':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rawinstream.c:62: undefined
reference to `read'

./lib/lib_rawoutstream.o: In function `rawoutstream_putc':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rawoutstream.c:61: undefined
reference to `write'

./lib/lib_rint.o: In function `rint':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:101: undefined
reference to `__aeabi_d2iz'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:102: undefined
reference to `__aeabi_i2d'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:102: undefined
reference to `__aeabi_dsub'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:104: undefined
reference to `__aeabi_dcmplt'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:108: undefined
reference to `__aeabi_dcmpeq'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:112: undefined
reference to `__aeabi_dcmplt'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:121: undefined
reference to `__aeabi_dcmpeq'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:125: undefined
reference to `__aeabi_dcmpgt'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_rint.c:131: undefined
reference to `__aeabi_i2d'

./lib/lib_strtod.o: In function `is_real':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:70: undefined
reference to `__aeabi_ddiv'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:71: undefined
reference to `__aeabi_dcmplt'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:71: undefined
reference to `__aeabi_dcmple'

./lib/lib_strtod.o: In function `strtod':

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:96: undefined
reference to `__aeabi_ddiv'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:125: undefined
reference to `__aeabi_dmul'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:125: undefined
reference to `__aeabi_i2d'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:125: undefined
reference to `__aeabi_dadd'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:138: undefined
reference to `__aeabi_dmul'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:138: undefined
reference to `__aeabi_i2d'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:138: undefined
reference to `__aeabi_dadd'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:212: undefined
reference to `__aeabi_ddiv'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:216: undefined
reference to `__aeabi_dmul'

C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_strtod.c:220: undefined
reference to `__aeabi_dmul'

./examples/usbserial/main.o: In function `user_start':

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:254:
undefined reference to `open'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:287:
undefined reference to `open'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:291:
undefined reference to `close'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:340:
undefined reference to `write'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:346:
undefined reference to `write'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:363:
undefined reference to `close'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:365:
undefined reference to `close'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:380:
undefined reference to `read'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:387:
undefined reference to `close'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:389:
undefined reference to `close'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:406:
undefined reference to `putchar'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:417:
undefined reference to `putchar'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:422:
undefined reference to `putchar'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:428:
undefined reference to `putchar'

C:\Firmware\Nuttx_Yagarto\Debug/../examples/usbserial/main.c:432:
undefined reference to `putchar'

./examples/usbserial/main.o:C:\Firmware\Nuttx_Yagarto\Debug/../examples/\
usbserial/main.c:437: more undefined references to `putchar' follow

./drivers/serial/lowconsole.o: In function `lowconsole_init':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/serial/lowconsole.c:131:
undefined reference to `register_driver'

./drivers/serial/serial.o: In function `uart_register':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/serial/serial.c:693:
undefined reference to `register_driver'

./drivers/can.o: In function `can_register':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/can.c:618: undefined
reference to `register_driver'

./drivers/dev_null.o: In function `devnull_register':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/dev_null.c:133: undefined
reference to `register_driver'

./drivers/dev_zero.o: In function `devzero_register':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/dev_zero.c:126: undefined
reference to `register_driver'

./drivers/loop.o: In function `loop_read':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:231: undefined
reference to `lseek'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:242: undefined
reference to `read'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:253: undefined
reference to `__aeabi_uidiv'

./drivers/loop.o: In function `loop_write':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:278: undefined
reference to `lseek'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:288: undefined
reference to `write'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:299: undefined
reference to `__aeabi_uidiv'

./drivers/loop.o: In function `losetup':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:363: undefined
reference to `stat'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:389: undefined
reference to `__aeabi_idiv'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:405: undefined
reference to `open'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:417: undefined
reference to `open'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:428: undefined
reference to `register_blockdriver'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:438: undefined
reference to `close'

./drivers/loop.o: In function `loteardown':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:471: undefined
reference to `open_blockdriver'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:481: undefined
reference to `close_blockdriver'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:494: undefined
reference to `unregister_blockdriver'

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/loop.c:500: undefined
reference to `close'

./drivers/ramdisk.o: In function `ramdisk_register':

C:\Firmware\Nuttx_Yagarto\Debug/../drivers/ramdisk.c:326: undefined
reference to `register_blockdriver'

./binfmt/libnxflat/libnxflat_init.o: In function `nxflat_init':

C:\Firmware\Nuttx_Yagarto\Debug/../binfmt/libnxflat/libnxflat_init.c:112\
: undefined reference to `open'

./binfmt/libnxflat/libnxflat_load.o: In function `nxflat_load':

C:\Firmware\Nuttx_Yagarto\Debug/../binfmt/libnxflat/libnxflat_load.c:163\
: undefined reference to `mmap'

./binfmt/libnxflat/libnxflat_read.o: In function `nxflat_read':

C:\Firmware\Nuttx_Yagarto\Debug/../binfmt/libnxflat/libnxflat_read.c:129\
: undefined reference to `lseek'

C:\Firmware\Nuttx_Yagarto\Debug/../binfmt/libnxflat/libnxflat_read.c:138\
: undefined reference to `read'

./binfmt/libnxflat/libnxflat_uninit.o: In function `nxflat_uninit':

C:\Firmware\Nuttx_Yagarto\Debug/../binfmt/libnxflat/libnxflat_uninit.c:8\
4: undefined reference to `close'

./arch/arm/src/chip/lpc313x_clkfreq.o: In function `lpc313x_clkfreq':

C:\Firmware\Nuttx_Yagarto\Debug/../arch/arm/src/chip/lpc313x_clkfreq.c:1\
72: undefined reference to `__aeabi_uidiv'

./arch/arm/src/chip/lpc313x_lowputc.o: In function `up_configbaud':

C:\Firmware\Nuttx_Yagarto\Debug/../arch/arm/src/chip/lpc313x_lowputc.c:1\
89: undefined reference to `__aeabi_uidiv'

C:\Firmware\Nuttx_Yagarto\Debug/../arch/arm/src/chip/lpc313x_lowputc.c:1\
98: undefined reference to `__aeabi_uidiv'

./arch/arm/src/chip/lpc313x_spi.o: In function `spi_setfrequency':

C:\Firmware\Nuttx_Yagarto\Debug/../arch/arm/src/chip/lpc313x_spi.c:424:
undefined reference to `__aeabi_uidiv'

C:\Firmware\Nuttx_Yagarto\Debug/../arch/arm/src/chip/lpc313x_spi.c:432:
undefined reference to `__aeabi_uidiv'

./arch/arm/src/chip/lpc313x_timerisr.o: In function `up_timerinit':

C:\Firmware\Nuttx_Yagarto\Debug/../arch/arm/src/chip/lpc313x_timerisr.c:\
136: undefined reference to `__aeabi_uldivmod'

collect2: ld returned 1 exit status

make: *** [Pulser_Plus_Nuttx_Yagarto.elf] Error 1
Post by Gregory Nutt
Hi, Nai,
... With your help, I was able to build all the .c and .s files. ...
I am glad to see that you are making progress!
... Now I run into library and linking problem. Here are the
errors.
Post by Gregory Nutt
Hope you can help me out.
I'll try.
first defined here Pulser_Plus_Nuttx_Yagarto
Some errors like this make no sense to me. Perhaps the error log was
mangled by
Post by Gregory Nutt
Yahoo! groups? I'll only respond to the errors that make sense to me
more undefined references to `IS_ALTFORM' follow
lib_libdtoa.c /Pulser_Plus_Nuttx_Yagarto/lib
I think I understand this one. This is because the file lib_libdtoa.c
is not
Post by Gregory Nutt
compiled directly. Rather, it is included within lib_vsprintf.c. I
did this in
Post by Gregory Nutt
this odd way because if you enable this floating point support, there are subtle
changes in the licensing because dtoa() is under the old BSD license.
lib_libvsprintf.c:192:# include "lib_libdtoa.c"
What you need to do is to remove the file lib_libdtoa.c from your project.
multiple definition of `getopt' ...
multiple definition of `optind' ...
multiple definition of `optopt' ...
My guess is that you are trying to link the NuttX libc with the some
other
Post by Gregory Nutt
libc. Make sure that you have -nostdlibs in your linker flags. These
are
Post by Gregory Nutt
defined in only one place in NuttX: lib/lib_getopt.c.
Pulser_Plus_Nuttx_Yagarto.elf section `.data' will not fit in region `isram'
...
This is some problem in your linker script. What linker script are
you using?
Post by Gregory Nutt
The normal ld.script file for the ea3131? The size of isram is 192Kb.
This
Post by Gregory Nutt
seems to be saying that the size of your image is larger than 192Kb.
By default, the ea3131 examples execute out of internal SRAM. If you
are
Post by Gregory Nutt
building something larger, you will probably have to change the ld.script file
so that the program linked for FLASH and use the lpc313x bootloader to save the
program to FLASH.
Pulser_Plus_Nuttx_Yagarto.elf: warning: sh_link not set for section
`.ARM.exidx' ...
This is not an error. Some toolchains generate this. Google for it,
lots of
Post by Gregory Nutt
people see it and it is apparently not harmful. But I don't see it
with
Post by Gregory Nutt
the toolchain that I use.
undefined reference to `devnull_register' up_initialize.c
Defined in the file drivers/dev_null.c. Either you need to add
dev_null.c in
Post by Gregory Nutt
your project or remove the call from up_initialize.c.
undefined reference to `lowconsole_init' up_initialize.c
Similar comments. lowconsole_init is defined in
drivers/serial/lowconsole.c
Post by Gregory Nutt
undefined reference to `mkfatfs' up_usbstrg.c
Defined in fs/fat/fs_mkfatfs.c
undefined reference to `ramdisk_register' up_usbstrg.c
Defined in drivers/ramdisk.c
no return statement in function returning non-void lpc313x_i2c.c
This is fixed in CVS.
Greg
Gregory Nutt
2010-08-18 20:32:05 UTC
Permalink
My project involve using lpc3130 to generate pulses. I design my board
using lpc3130 with no external memmory. I run my code from the 96k of
SRAM. Would you mind show me how to use a strip down barebone version of
Nuttx that will fit in a small memory area. All I need is the RTOS without
file system, graphics, net, huge libraries (just some useful popular one
like printf).
All you need to do it to change your configuration file to disable the features
that you don't want.  As examples:

CONFIG_NFILE_DESCRIPTORS=0 will disable the file system support.
CONFIG_NX=n will disable graphics
CONFIG_NET=n will disable graphics

Look at configs/pjrc-8051/defconfig.  This a configuration for the 8052 that ran
with the ostest application, all .text, all .data, all .bss, and all heap in
32Kb of memory.  That is as stripped down a system as I have built and may be
something like you are looking for. 


As a warning, I have not built such a stripped down system in a long, long
time.  So there make have been some compile errors creep in.

Hmmm... looking below, I don't think that your problem is that you have too many
things enabled, I think you are building the NuttX library wrong.  See below.
C:\Firmware\Nuttx_Yagarto\Debug/../sched/sched_releasefiles.c:80: undefined
reference to `files_releaselist'
... `sched_setupidlefiles' ... `files_alloclist' ... `open' ... `dup2' ...
`close' .. etc.
These dependencies should all disappear if you have CONFIG_NFILE_DESCRIPTORS=0.
C:\Firmware\Nuttx_Yagarto\Debug/../lib/lib_fread.c:96: undefined reference to
`__aeabi_uidiv' ...
`__aeabi_uldivmod' ... `__aeabi_ui2d' ... `__aeabi_dmul' ... `__aeabi_d2uiz'
... etc.
These all come from libgcc.a which is a part of your toolchain.  When you added
-nostdlib, it stopped automatically including libgcc.a.  You will need to add
the explicit path to libgcc.a if you also use -nostdlib.

See below.  The problem is in the way you are trying to build NuttX.  You can
probably take the -nostdlib back out.
Why do you link in qsort? nrand? frand?  I think you probably have more files in
your project than you need.  Normally, NuttX builds to a static library.  Then
you link against the static library; the link then naturally only takes out what
you actually use.  I suspect that you are not building a static library but,
instead, trying to build the whole NuttX source try into an executable?  If you
do that, it will be huge and will contain lots of code that you don't need.  I
don't think you will ever be succesful doing that.

In your project, you should make a library, not a fully linked executable.

That probably completely accounts for the problem that you are having with
size.  It probably has nothing to do with the filesystem nor does it have
anything to do with the -nostdlib (you can take that back out and it will find
libgcc.a okay).
If you disable file descriptors, you will not be able to use usbserial or any
other device drivers.

Greg
Gregory N
2010-08-18 23:24:40 UTC
Permalink
Post by Nai
My project involve using lpc3130 to generate pulses. I design my board
using lpc3130 with no external memmory. I run my code from the 96k of
SRAM. Would you mind show me how to use a strip down barebone version
of Nuttx that will fit in a small memory area. ...
If you get past your build issues, you should not have any trouble with examples/usbserial in on your lpc3130 with 96Kb of memory. I just re-built that configuration (correctly) and measured the size. Here are the steps I used:

cd tools/
./configure.sh ea3131/usbserial
cd ..
vi setenv.sh (fix path to gcc)
. ./setenv.sh
make CROSSDEV=arm-elf-

And the result was:

arm-elf-size nuttx
text data bss dec hex filename
55292 106 7648 63046 f646 nuttx

The whole program should fit into SRAM and leave a good, healthy space for a heap.

NOTE: I did see a compilation error in drivers/usbdev/usbdev_serial.c because (apparently) that file had never compiled with
CONFIG_USBDEV_DUALSPEED enabled). The fix is in CVS and shown below:

Index: usbdev_serial.c
===================================================================
RCS file: /cvsroot/nuttx/nuttx/drivers/usbdev/usbdev_serial.c,v
retrieving revision 1.24
diff -u -r1.24 usbdev_serial.c
--- usbdev_serial.c 28 Mar 2010 21:41:49 -0000 1.24
+++ usbdev_serial.c 18 Aug 2010 23:18:25 -0000
@@ -318,7 +318,7 @@

static int usbclass_mkstrdesc(uint8_t id, struct usb_strdesc_s *strdesc);
#ifdef CONFIG_USBDEV_DUALSPEED
-static void usbclass_mkepbulkdesc(const struct usb_epdesc *indesc,
+static void usbclass_mkepbulkdesc(const struct usb_epdesc_s *indesc,
uint16_t mxpacket, struct usb_epdesc_s *outdesc);
static int16_t usbclass_mkcfgdesc(uint8_t *buf, uint8_t speed, uint8_t type);
#else
@@ -864,7 +864,7 @@
****************************************************************************/

#ifdef CONFIG_USBDEV_DUALSPEED
-static inline void usbclass_mkepbulkdesc(const FAR struct usb_epdesc *indesc,
+static inline void usbclass_mkepbulkdesc(const FAR struct usb_epdesc_s *indesc,
uint16_t mxpacket,
FAR struct usb_epdesc_s *outdesc)
{
@@ -1054,7 +1054,7 @@
/* Configure the IN bulk endpoint */

#ifdef CONFIG_USBDEV_DUALSPEED
- if ((priv->usbdev->speed == USB_SPEED_HIGH)
+ if (priv->usbdev->speed == USB_SPEED_HIGH)
{
bulkmxpacket = 512;
}
Nai
2010-08-23 18:46:01 UTC
Permalink
Thanks Greg. I used your method and built successful.

I wish I can use a autobuild and auto linking tool in Eclipse IDE like the GNU ARM Eclipse Plug-in. However, this will not work because like you said, the auto linking is trying to link the whole Nuttx source into an executable.

Well at least I can do what lharnoldii did and use Eclipse to browse definitions and references, and do all the other cool things IDEs give you.
Post by Gregory N
Post by Nai
My project involve using lpc3130 to generate pulses. I design my board
using lpc3130 with no external memmory. I run my code from the 96k of
SRAM. Would you mind show me how to use a strip down barebone version
of Nuttx that will fit in a small memory area. ...
cd tools/
./configure.sh ea3131/usbserial
cd ..
vi setenv.sh (fix path to gcc)
. ./setenv.sh
make CROSSDEV=arm-elf-
arm-elf-size nuttx
text data bss dec hex filename
55292 106 7648 63046 f646 nuttx
The whole program should fit into SRAM and leave a good, healthy space for a heap.
NOTE: I did see a compilation error in drivers/usbdev/usbdev_serial.c because (apparently) that file had never compiled with
Index: usbdev_serial.c
===================================================================
RCS file: /cvsroot/nuttx/nuttx/drivers/usbdev/usbdev_serial.c,v
retrieving revision 1.24
diff -u -r1.24 usbdev_serial.c
--- usbdev_serial.c 28 Mar 2010 21:41:49 -0000 1.24
+++ usbdev_serial.c 18 Aug 2010 23:18:25 -0000
@@ -318,7 +318,7 @@
static int usbclass_mkstrdesc(uint8_t id, struct usb_strdesc_s *strdesc);
#ifdef CONFIG_USBDEV_DUALSPEED
-static void usbclass_mkepbulkdesc(const struct usb_epdesc *indesc,
+static void usbclass_mkepbulkdesc(const struct usb_epdesc_s *indesc,
uint16_t mxpacket, struct usb_epdesc_s *outdesc);
static int16_t usbclass_mkcfgdesc(uint8_t *buf, uint8_t speed, uint8_t type);
#else
@@ -864,7 +864,7 @@
****************************************************************************/
#ifdef CONFIG_USBDEV_DUALSPEED
-static inline void usbclass_mkepbulkdesc(const FAR struct usb_epdesc *indesc,
+static inline void usbclass_mkepbulkdesc(const FAR struct usb_epdesc_s *indesc,
uint16_t mxpacket,
FAR struct usb_epdesc_s *outdesc)
{
@@ -1054,7 +1054,7 @@
/* Configure the IN bulk endpoint */
#ifdef CONFIG_USBDEV_DUALSPEED
- if ((priv->usbdev->speed == USB_SPEED_HIGH)
+ if (priv->usbdev->speed == USB_SPEED_HIGH)
{
bulkmxpacket = 512;
}
Gregory Nutt
2010-08-23 19:24:49 UTC
Permalink
Post by Nai
I wish I can use a autobuild and auto linking tool in Eclipse IDE like the GNU
ARM Eclipse Plug-in.
Can you set up the IDE to build a library?  Wouldn't that be one of the target
options?  That would be the ideal way to build the system:  Build a library
first as one of the make dependencies, then link against the library?

I know someone else who set up an IDE like this:

1. Build the NuttX libaries (lib*.a) using the command line make, then
2. Set up a project, replacing the standard startup file with the NuttX startup
file (for your case, that would be arch/arm/src/up_head.o),

3. Add all of your application files to the IDE
4. Configure all of the NuttX libaries to link against, and
5. Then just build the application files and link the startup, application
files, and the NuttX libaries.

That works okay.  But it is is difficult to debug NuttX code itself, because the
IDE doesn't know where to find the source files (you can, however,  tell GDB
where to find the source files).  There is a work-around for that, however.  You
can temporarily bring NuttX files into the project and rebuild.  In this case,
the IDE will take the object it built instead of the one from the NuttX
library.  Then the debugger should be able to find the symbols.

I would like to have a make system that is flexible, builds the smallest
possible executables, and is not dependent on any particular build environment. 
That is pretty much impossible.  If anyone can suggest any improvements to the
build system to make it  more use-able in different environments, I'll consider
the changes.

Greg
lharnoldii
2010-08-23 21:20:34 UTC
Permalink
Maybe you miss my point. Create a new c project in eclipse. make it an "empty makefile project". Import the top level nuttx directory (after you build it once).

Now you are using the nuttx makefile system from within eclipse, with all the eclipse build automation. You are NOT using the eclipse/CDT build system. Make any build changes the same way you would from a console.

You could build a plug in for eclipse to do all the magic in the background, but that's a pretty heavy undertaking, especially when you have a complete make environment to work from.

Working now on OpenOCD... Got it working from the command line (debian linux.) The following directions look pretty straight forward as far as creating eclipse build targets for flashing and debugging:

http://www.makingthings.com/documentation/tutorial/debug-with-openocd/configure-eclipse

I'm afraid to brick my chip though, before I can figure out how to debug it.

I want to run "nsh", but my Stellaris EKC-LM3S8962 doesn't seem to have a serial port for a terminal. Can I use the one on the ftdi FT2232C dongle interface? Dmesg reports "usb 4-1: FTDI USB Serial Device converter now attached to ttyUS", but also says "usb 4-1: Ignoring serial port reserved for JTAG"

If worse comes to worse I have a max 3223 lying around I could interface to a UART port with.

I did have to make some small changes to the include files for the 8962... but mostly interrupts were additions for new devices (CANbus) and omissions for devices that weren't there, like UART2. No conflicts. memory map is the same.When I'm sure it's working right I'll send you the changes. Ti sells it with a LM3S2110 sub card for like 80$
Post by Gregory Nutt
Post by Nai
I wish I can use a autobuild and auto linking tool in Eclipse IDE like the GNU
ARM Eclipse Plug-in.
Can you set up the IDE to build a library?  Wouldn't that be one of the target
options?  That would be the ideal way to build the system:  Build a library
first as one of the make dependencies, then link against the library?
1. Build the NuttX libaries (lib*.a) using the command line make, then
2. Set up a project, replacing the standard startup file with the NuttX startup
file (for your case, that would be arch/arm/src/up_head.o),
3. Add all of your application files to the IDE
4. Configure all of the NuttX libaries to link against, and
5. Then just build the application files and link the startup, application
files, and the NuttX libaries.
That works okay.  But it is is difficult to debug NuttX code itself, because the
IDE doesn't know where to find the source files (you can, however,  tell GDB
where to find the source files).  There is a work-around for that, however.  You
can temporarily bring NuttX files into the project and rebuild.  In this case,
the IDE will take the object it built instead of the one from the NuttX
library.  Then the debugger should be able to find the symbols.
I would like to have a make system that is flexible, builds the smallest
possible executables, and is not dependent on any particular build environment. 
That is pretty much impossible.  If anyone can suggest any improvements to the
build system to make it  more use-able in different environments, I'll consider
the changes.
Greg
Gregory N
2010-08-23 21:50:28 UTC
Permalink
Maybe you miss my point. ...
I don't use IDEs, so I try to be helpful but in reality the conversations just blow by me -- sorry. I'm sure your information will be important to other people on the list!
I want to run "nsh", but my Stellaris EKC-LM3S8962 doesn't seem
to have a serial port for a terminal. Can I use the one on the ftdi
FT2232C dongle interface? Dmesg reports "usb 4-1: FTDI USB Serial
Ignoring serial port reserved for JTAG"
I bet that is because you have a FT2232 driver installed for a JTAG device. Maybe you can't use both a generic FT2232 serial and FT2232 JTAG device simultaneously? My olimex FT2232 JTAG reports itself as a compound device, it is both a serial device and a JTAG device.

Another option is to use a network and telnet to NSH. There are some other people on this forum struggling with the same serial issue for a different LM3S:

http://tech.groups.yahoo.com/group/nuttx/message/408
http://tech.groups.yahoo.com/group/nuttx/message/430

Of course, you can only use telnet if your network is working. And you may not be able to get the network working without a serial console.
If worse comes to worse I have a max 3223 lying around I could
interface to a UART port with.
That is not really a bad option.
.. When I'm sure it's working right I'll send you the changes.
Great!

Greg
Nai
2010-08-24 14:25:32 UTC
Permalink
Thanks Larnold,
I believe you are using Linux Eclipse, and I'm using windows Eclipse that's why I have a hard time compiling.

I did as you said: Create a new c project in eclipse. make it an "empty makefile project". Import the top level nuttx directory (after you build it once).

And I fixed a small path problem in Windows as follow:

In the makefile line 36:
#TOPDIR := ${shell pwd | sed -e 's/ /\\ /g'}

For some reason unknown to me, this does not generate the / in the path. I hardcode in the path to my project C:/myproject/nuttx and it compiled successful.
Post by lharnoldii
Maybe you miss my point. Create a new c project in eclipse. make it an "empty makefile project". Import the top level nuttx directory (after you build it once).
Now you are using the nuttx makefile system from within eclipse, with all the eclipse build automation. You are NOT using the eclipse/CDT build system. Make any build changes the same way you would from a console.
You could build a plug in for eclipse to do all the magic in the background, but that's a pretty heavy undertaking, especially when you have a complete make environment to work from.
http://www.makingthings.com/documentation/tutorial/debug-with-openocd/configure-eclipse
I'm afraid to brick my chip though, before I can figure out how to debug it.
I want to run "nsh", but my Stellaris EKC-LM3S8962 doesn't seem to have a serial port for a terminal. Can I use the one on the ftdi FT2232C dongle interface? Dmesg reports "usb 4-1: FTDI USB Serial Device converter now attached to ttyUS", but also says "usb 4-1: Ignoring serial port reserved for JTAG"
If worse comes to worse I have a max 3223 lying around I could interface to a UART port with.
I did have to make some small changes to the include files for the 8962... but mostly interrupts were additions for new devices (CANbus) and omissions for devices that weren't there, like UART2. No conflicts. memory map is the same.When I'm sure it's working right I'll send you the changes. Ti sells it with a LM3S2110 sub card for like 80$
Post by Gregory Nutt
Post by Nai
I wish I can use a autobuild and auto linking tool in Eclipse IDE like the GNU
ARM Eclipse Plug-in.
Can you set up the IDE to build a library?  Wouldn't that be one of the target
options?  That would be the ideal way to build the system:  Build a library
first as one of the make dependencies, then link against the library?
1. Build the NuttX libaries (lib*.a) using the command line make, then
2. Set up a project, replacing the standard startup file with the NuttX startup
file (for your case, that would be arch/arm/src/up_head.o),
3. Add all of your application files to the IDE
4. Configure all of the NuttX libaries to link against, and
5. Then just build the application files and link the startup, application
files, and the NuttX libaries.
That works okay.  But it is is difficult to debug NuttX code itself, because the
IDE doesn't know where to find the source files (you can, however,  tell GDB
where to find the source files).  There is a work-around for that, however.  You
can temporarily bring NuttX files into the project and rebuild.  In this case,
the IDE will take the object it built instead of the one from the NuttX
library.  Then the debugger should be able to find the symbols.
I would like to have a make system that is flexible, builds the smallest
possible executables, and is not dependent on any particular build environment. 
That is pretty much impossible.  If anyone can suggest any improvements to the
build system to make it  more use-able in different environments, I'll consider
the changes.
Greg
Nai
2010-08-24 14:37:41 UTC
Permalink
Oh, and I also have to comment out these from the makefile:

# Build the mkconfig tool used to create include/nuttx/config.h
#tools/mkconfig:
# @$(MAKE) -C tools -f Makefile.mkconfig TOPDIR="$(TOPDIR)" mkconfig

# Create the include/nuttx/config.h file
#include/nuttx/config.h: $(TOPDIR)/.config tools/mkconfig
# tools/mkconfig $(TOPDIR) > include/nuttx/config.h
Post by Nai
Thanks Larnold,
I believe you are using Linux Eclipse, and I'm using windows Eclipse that's why I have a hard time compiling.
I did as you said: Create a new c project in eclipse. make it an "empty makefile project". Import the top level nuttx directory (after you build it once).
#TOPDIR := ${shell pwd | sed -e 's/ /\\ /g'}
For some reason unknown to me, this does not generate the / in the path. I hardcode in the path to my project C:/myproject/nuttx and it compiled successful.
Post by lharnoldii
Maybe you miss my point. Create a new c project in eclipse. make it an "empty makefile project". Import the top level nuttx directory (after you build it once).
Now you are using the nuttx makefile system from within eclipse, with all the eclipse build automation. You are NOT using the eclipse/CDT build system. Make any build changes the same way you would from a console.
You could build a plug in for eclipse to do all the magic in the background, but that's a pretty heavy undertaking, especially when you have a complete make environment to work from.
http://www.makingthings.com/documentation/tutorial/debug-with-openocd/configure-eclipse
I'm afraid to brick my chip though, before I can figure out how to debug it.
I want to run "nsh", but my Stellaris EKC-LM3S8962 doesn't seem to have a serial port for a terminal. Can I use the one on the ftdi FT2232C dongle interface? Dmesg reports "usb 4-1: FTDI USB Serial Device converter now attached to ttyUS", but also says "usb 4-1: Ignoring serial port reserved for JTAG"
If worse comes to worse I have a max 3223 lying around I could interface to a UART port with.
I did have to make some small changes to the include files for the 8962... but mostly interrupts were additions for new devices (CANbus) and omissions for devices that weren't there, like UART2. No conflicts. memory map is the same.When I'm sure it's working right I'll send you the changes. Ti sells it with a LM3S2110 sub card for like 80$
Post by Gregory Nutt
Post by Nai
I wish I can use a autobuild and auto linking tool in Eclipse IDE like the GNU
ARM Eclipse Plug-in.
Can you set up the IDE to build a library?  Wouldn't that be one of the target
options?  That would be the ideal way to build the system:  Build a library
first as one of the make dependencies, then link against the library?
1. Build the NuttX libaries (lib*.a) using the command line make, then
2. Set up a project, replacing the standard startup file with the NuttX startup
file (for your case, that would be arch/arm/src/up_head.o),
3. Add all of your application files to the IDE
4. Configure all of the NuttX libaries to link against, and
5. Then just build the application files and link the startup, application
files, and the NuttX libaries.
That works okay.  But it is is difficult to debug NuttX code itself, because the
IDE doesn't know where to find the source files (you can, however,  tell GDB
where to find the source files).  There is a work-around for that, however.  You
can temporarily bring NuttX files into the project and rebuild.  In this case,
the IDE will take the object it built instead of the one from the NuttX
library.  Then the debugger should be able to find the symbols.
I would like to have a make system that is flexible, builds the smallest
possible executables, and is not dependent on any particular build environment. 
That is pretty much impossible.  If anyone can suggest any improvements to the
build system to make it  more use-able in different environments, I'll consider
the changes.
Greg
Gregory N
2010-08-26 23:57:29 UTC
Permalink
Post by Nai
I believe you are using Linux Eclipse, and I'm using windows
Eclipse that's why I have a hard time compiling.
Eclipse + Cygwin:

I am not an Eclipse expert (or even an Eclipse user), so I hesitate to comment. But ignorance has never stopped me in the past...

I have a friend where I work who builds our Makefile-based Linux code with Eclipse under Windows. The Linux code/Make system is installed in Cygwin and Eclipse builds from Cygwin GCC - just as you would build NuttX.

I think the trick is the you have to set up Eclipse specially to work with Cygwin. You not only have to set up an "empty makefile project" as was mentioned before, but I think you also have to select "Gygwin GCC."

Look at: http://www.google.co.cr/search?q=eclipse+cygwin&ie=utf-8&oe=utf-8

For example:

http://homepage.cs.uri.edu/courses/fall2007/csc406/Handouts/eclipseTutorial.pdf
http://stackoverflow.com/questions/1450654/eclipse-cdt-with-cygwin-gcc-automatic-discovery-of-symbols-and-paths
and several others

I believe Eclipse should work fine with a Cygwin, Makefile project if properly set up.

GNUWin32:

Earlier in this list, I recall that someone mentioned that they had NuttX build native on Windows using GNUWin32. I recall that the only real issue is that they had to change the Cygwin (via ln) links to NTFS links (via mklinks).
lharnoldii
2010-08-17 21:47:34 UTC
Permalink
This worked for me, building for a Stellaris EKC-LM3S8962, which ( so far ) seems similar to the lm3s6965-ek buld. On Linux. YMMV

Use plain Vanilla Eclipse and CDT.

I used the same setup for a coldfire build, but using scons instead. eclipse doesn't care.

1. build a toolchain with the buildroot package. Or use Yagarto if it works from a console.
2. you have already configured for your CPU now (if you did buildroot), but run setenv.sh and then make to see if it works.
3. O.K.! it works. fire up eclipse, and create a new makefile c project. I called mine nuttx
4. right click on the project, browse to your nuttx installation, and import everything into your eclipse workspace. select "copy files", so you don't corrupt anything in your nuttx install while playing around.
5. source setenv.sh somewhere and find out where your toolchain is.
6. right click on nuttx again, go to properties, select c/c++ build,environment, and add a PATH variable.
7.edit the PATH variable,prepend the path to the toolchain in it (it's a colon separator, not a semi colon)
8. rightclick the project and clean it. Otherwise nothing will happen. the right click and build it. ZOUNDS!

once I get OPENOCD running it should be a cinch to GDB away. probably load flash automatically on entering a debug session too. We'll see.

But right now I can use eclipse to browse definitions and references, and do all the other cool things IDEs give you.
Post by Nai
Hi Greg,
Thanks for your advice. I decided to drop the Red Suite IDE and use an
open source IDE - Yagarto and Eclipse IDE.
Installed Yagarto tool chain.
Installed Eclipse Helios
Installed GNU ARM Eclipse Plug-in. GNU ARM Eclipse Plug-in managed all
the build and linking inside Eclipse. I'm don't know anything about
make files and linking script, so I use this plug-in.
I tried to build the EA3131 Board with only modules that I need.
I followed your advice by doing all the steps in
configs/ea3131/README.txt under the heading "IDEs"
With your help, I was able to build all the .c and .s files. Now I run
into library and linking problem. Here are the errors. Hope you can
help me out.
Description
Resource
Path
first defined here
Pulser_Plus_Nuttx_Yagarto
first defined here
Pulser_Plus_Nuttx_Yagarto
first defined here
lib_getopt.c
/Pulser_Plus_Nuttx_Yagarto/lib
make: *** [Pulser_Plus_Nuttx_Yagarto.elf] Error 1
Pulser_Plus_Nuttx_Yagarto
more undefined references to `IS_ALTFORM' follow
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
multiple definition of `getopt'
Pulser_Plus_Nuttx_Yagarto
multiple definition of `optind'
Pulser_Plus_Nuttx_Yagarto
multiple definition of `optopt'
Pulser_Plus_Nuttx_Yagarto
Pulser_Plus_Nuttx_Yagarto.elf section `.data' will not fit in region
`isram'
Pulser_Plus_Nuttx_Yagarto
Pulser_Plus_Nuttx_Yagarto.elf: warning: sh_link not set for section
`.ARM.exidx'
Pulser_Plus_Nuttx_Yagarto
region `isram' overflowed by 20840 bytes
Pulser_Plus_Nuttx_Yagarto
undefined reference to `devnull_register'
up_initialize.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/common
undefined reference to `IS_ALTFORM'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
undefined reference to `IS_ALTFORM'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
undefined reference to `IS_ALTFORM'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
undefined reference to `IS_ALTFORM'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
undefined reference to `IS_ALTFORM'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
undefined reference to `lowconsole_init'
up_initialize.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/common
undefined reference to `mkfatfs'
up_usbstrg.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/board
undefined reference to `ramdisk_register'
up_usbstrg.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/board
WARNINGS
'lib_dtoa' defined but not used
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
#warning "Not implemented"
lpc313x_irq.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/chip
#warning "timer_getoverrun not Implemented"
timer_getoverrun.c
/Pulser_Plus_Nuttx_Yagarto/sched
assignment discards qualifiers from pointer target type
lpc313x_i2c.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/chip
assignment makes pointer from integer without a cast
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
implicit declaration of function '__dtoa'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
implicit declaration of function 'IS_ALTFORM'
lib_libdtoa.c
/Pulser_Plus_Nuttx_Yagarto/lib
implicit declaration of function 'ramdisk_register'
up_usbstrg.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/board
no return statement in function returning non-void
lpc313x_i2c.c
/Pulser_Plus_Nuttx_Yagarto/arch/arm/src/chip
too many arguments for format
barrier.c
/Pulser_Plus_Nuttx_Yagarto/examples/ostest
too many arguments for format
barrier.c
/Pulser_Plus_Nuttx_Yagarto/examples/ostest
too many arguments for format
mqueue.c
/Pulser_Plus_Nuttx_Yagarto/examples/ostest
Post by Gregory N
Post by Nai
I'm trying to compile Nuttx for the LPC3131 in Red Suite 3 IDE with
no success. Is this because of the GCC version 4.2.4 used in
Buildroot is different from the GCC used on Red Suite?
It looks like Red Suite is a version of Eclipse w/GNU tools tuned to
support NXP products. Is that right?
Post by Gregory N
I would not think that there would be any major incompatibilities
between the GNU toolchains. But I would have to see the errors you are
getting before I could give you any advice. Can you post the errors?
Post by Gregory N
On probable issue is the Buildroot is a native Linux or Cygwin
toolchain. Most likely, the GNU tools in Red Suite are Windows native
tools. Look at configs/ea3131/README.txt in the section Youner "GNU
Toolchain Options". You might try setting CONFIG_LPC3131_CODESOURCERYW
in you .config file. You may need to make addition customizations to the
top-level Make.defs file.
Post by Gregory N
There are other complexities for using an IDE to build NuttX. There is
some discussion of this in configs/ea3131/README.txt under the heading
"IDEs"
Post by Gregory N
Greg
Gregory N
2010-08-17 22:32:54 UTC
Permalink
Post by lharnoldii
This worked for me, building for a Stellaris EKC-LM3S8962, which
( so far ) seems similar to the lm3s6965-ek buld. ...
I bet you will eventually see some differences. There are usually some differences like the type and number of supported peripherals, internal FLASH/SRAM size, or pin multiplexing.

If you suspect chip differences at some point, here is the list of things in the source tree you might want to check: http://tech.groups.yahoo.com/group/nuttx/message/409

Greg
Larry Arnold
2010-09-02 22:50:02 UTC
Permalink
Post by lharnoldii
This worked for me, building for a Stellaris EKC-LM3S8962, which
( so far ) seems similar to the lm3s6965-ek buld. ...
I bet you will eventually see some differences. There are usually some
differences like the type and number of supported peripherals,
internal FLASH/SRAM size, or pin multiplexing.
If you suspect chip differences at some point, here is the list of
http://tech.groups.yahoo.com/group/nuttx/message/409
Greg
Ah yes. there were some differences... a couple of pins moved due to the
CAN interface, a missing serial port. Other than that the chips (and
boards) are surprisingly similar.
I did notice some additions for the LM3S9B96 in 5.9. That's a little
different , 'cause the LM3S9B96 has more than 2 options for GPIO pins in
many cases.

Haven't figured out how to send attachments to yahoo, but there's a zip
file coming along somehow with the necessary changes. Not sure if they
work.. testing now, so I'll give you updates.

I have figured out how to build nuttx in eclipse, at least on Linux.
Browsing, searching, auto-compiling, definitions and references, the
whole bit. Using Openocd I can flash the chip, or start a debugger with
a single click, and start tracing source code. Schweet. I do need to
disable the watchdog though... it's not happy when you stop execution.
I'll put together a howto in the next couple of days if you want. Should
work on Cygwin too.

There's a bug in GDB6.8's build.. it defaults to -Werror, and
compilation halts because of warnings. I couldn't figure out how to
build it with Buildroot, So I just built GDB7.0 from scratch. It sees to
work fine. 7.1 still has issues.

Openocd is a hardware replacement for gdbserver, interfacing to GDB in
the same way,but using the ftdi JTAG interface on the stellaris board.
USB speed. The serial port is brought out as a virtual USB serial port.
I just plugged it in, and Debian loaded it all up ( after apt-getting
openocd) with no complaints. A few tweeks to the configuration files and
off I went.Gdbserver might be faster, but the licensing would be weird.
You'd have to link it to your code to use it, so that GPLs your code.
but after you are done, you unlink it, is your code still GPLed? too
confusing. I'll stick to the hardware solution.

The patch for CONFIG_EXAMPLE=foobar with CONFIG_APP_DIR makes sense. The
examples are little applications after all, and being able to specify an
app directory potentially provides some separation between the OS tree
and an application tree.


Anyway, now on to testing the stellaris port.

Cheers.
Tiago Maluta
2010-09-02 23:07:51 UTC
Permalink
[Attachment(s) from Larry Arnold included below]
Attachments seem to be corrupted.

$ file nuttx59_8962.tar.bz2
nuttx59_8962.tar.bz2: HTML document text
I have figured out how to build nuttx in eclipse, at least on Linux.
Cool!
Openocd is a hardware replacement for gdbserver, interfacing to GDB in
the same way,but using the ftdi JTAG interface on the stellaris board.
USB speed. The serial port is brought out as a virtual USB serial port.
I just plugged it in, and Debian loaded it all up ( after apt-getting
openocd) with no complaints. A few tweeks to the configuration files and
off I went.Gdbserver might be faster, but the licensing would be weird.
You'd have to link it to your code to use it, so that GPLs your code.
but after you are done, you unlink it, is your code still GPLed? too
confusing. I'll stick to the hardware solution.
I'd like to compare your .cfg files.
I tried openocd with EKK-LM3S9B96 Evaluation Kit but still getting
some clock issues. (i.e. telnet freezes)

--tm
Larry Arnold
2010-09-02 23:30:33 UTC
Permalink
Try this
Post by Tiago Maluta
[Attachment(s) from Larry Arnold included below]
Attachments seem to be corrupted.
$ file nuttx59_8962.tar.bz2
nuttx59_8962.tar.bz2: HTML document text
I have figured out how to build nuttx in eclipse, at least on Linux.
Cool!
Openocd is a hardware replacement for gdbserver, interfacing to GDB in
the same way,but using the ftdi JTAG interface on the stellaris board.
USB speed. The serial port is brought out as a virtual USB serial port.
I just plugged it in, and Debian loaded it all up ( after apt-getting
openocd) with no complaints. A few tweeks to the configuration files and
off I went.Gdbserver might be faster, but the licensing would be weird.
You'd have to link it to your code to use it, so that GPLs your code.
but after you are done, you unlink it, is your code still GPLed? too
confusing. I'll stick to the hardware solution.
I'd like to compare your .cfg files.
I tried openocd with EKK-LM3S9B96 Evaluation Kit but still getting
some clock issues. (i.e. telnet freezes)
--tm
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3108 - Release Date: 09/02/10 02:34:00
Tiago Maluta
2010-09-03 00:52:13 UTC
Permalink
[Attachment(s) from Larry Arnold included below]
Try this
Now it works.

--tm

Gregory Nutt
2010-09-02 23:14:42 UTC
Permalink
Post by Larry Arnold
Haven't figured out how to send attachments to yahoo, but there's a zip
file coming along somehow with the necessary changes. Not sure if they
work.. testing now, so I'll give you updates.
Attachments end up in that Messages/Attachments folder:
http://groups.yahoo.com/group/nuttx/attachments/folder/0/list . Looks like it is
there; I'll get it tonight.
Post by Larry Arnold
I'll put together a howto in the next couple of days if you want.
That would be great.  You can post files and documents in the group Files
folder.
Post by Larry Arnold
There's a bug in GDB6.8's build.. it defaults to -Werror, and
compilation halts because of warnings. I couldn't figure out how to
build it with Buildroot, So I just built GDB7.0 from scratch. It sees to
work fine. 7.1 still has issues.
See bullet 7 here: http://sourceware.org/gdb/wiki/FAQ . Looks you need to add
--disable-werror to the configuration line. I added that to the buildroot gdb.mk
file (not yet tested).
Post by Larry Arnold
Gdbserver might be faster, but the licensing would be weird.
You'd have to link it to your code to use it, so that GPLs your code.
but after you are done, you unlink it, is your code still GPLed? too
confusing. I'll stick to the hardware solution.
GPL only applies when you deliver binaries.  What you do in the privacy of your
own home is you own business; just don't ship binaries with GPL included unless
you conform to the license.

gdbserver has one interesting capability the OpenOCD does not:  You could do
thread aware debugging:  When you are hit a breakpoint in common code (like
printf), it would only stop on the task that you are debugging, not other tasks
that use printf.  That is not useful for porting or doing OS development, but it
is great for application development.  KGDB is the non-thread aware version.

I'll let you know after the changes are incorporated.

Greg
Loading...