[ECOS] Eclipse / CDT without Makefile Project

[ECOS] Eclipse / CDT without Makefile Project

[Michael Jones]

I have been trying to make an Eclipse/CDT (Juno) project for eCos, but not a Makefile project. Mainly so that it can navigate to h files, and try to see if it will drive GDB.

Eclipse seems to ignore linker options and do its own thing. For example, for the linker I have:

-mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -T../../ecos/TWR-K60D100M_install/lib/target.ld

But, it appears that some options, like -T are ignored. And the linker tries to link in crt0.o, even if I set the compile options to not include startup files. What is surprising is Eclipse make a makefile that seemed correct. Although, I am not a gcc/make expert. I did notice it puts all the options on one line, rather than splitting the build into compile and link. Perhaps that is part of the problem. See the makefile below.

Is there a way to make Eclipse strictly obey all my options and build properly?

Does anyone have a simple project I can look at to see how to set this up?

Is this a complete waste of my time?

Mike

Generated Makefile

################################################################################
# Automatically-generated file. Do not edit!
################################################################################

-include ../makefile.init

RM := rm -rf

# All of the sources participating in the build are defined here
-include sources.mk
-include Sources/subdir.mk
-include subdir.mk
-include objects.mk

ifneq ($(MAKECMDGOALS),clean)
ifneq ($(strip $(C_DEPS)),)
-include $(C_DEPS)
endif
endif

-include ../makefile.defs

# Add inputs and outputs from these tool invocations to the build variables 

# All Target
all: hello_world

# Tool invocations
hello_world: $(OBJS) $(USER_OBJS)
	@echo 'Building target: $@'
	@echo 'Invoking: Cross GCC Linker'
	arm-eabi-gcc -nostartfiles -nodefaultlibs -nostdlib -static -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -T../../ecos/TWR-K60D100M_install/lib/target.ld -o "hello_world" $(OBJS) $(USER_OBJS) $(LIBS)
	@echo 'Finished building target: $@'
	@echo ' '

# Other Targets
clean:
	-$(RM) $(OBJS)$(C_DEPS)$(EXECUTABLES) hello_world
	-@echo ' '

.PHONY: all clean dependents
.SECONDARY:

-include ../makefile.targets


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Eclipse / CDT without Makefile Project

[John Dallaway]

Mike

On 20/12/12 07:44, Michael Jones wrote:

> I have been trying to make an Eclipse/CDT (Juno) project for eCos, but not a
> Makefile project. Mainly so that it can navigate to h files, and try to see
> if it will drive GDB.
> 
> Eclipse seems to ignore linker options and do its own thing. For example, for
> the linker I have:
> 
> -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -T../../ecos/TWR-K60D100M_install/lib/target.ld
> 
> But, it appears that some options, like -T are ignored. And the linker tries
> to link in crt0.o, even if I set the compile options to not include startup
> files.

You are missing the -L linker option specifying the library search path
(location of libtarget.a). Try modifying your command line as follows:

> -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -Ttarget.ld

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Michael Jones]

John,

Thanks, now it is closer. I have provided the output showing the final failure:

/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lg
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [Sources/hello.o] Error 1

07:56:20 Build Finished (took 929ms)

What is interesting is that even with the -L option, it does not show up in the compile output.

The rule it makes in the makefile is

hello_world: $(OBJS) $(USER_OBJS)
	@echo 'Building target: $@'
	@echo 'Invoking: Cross GCC Linker'
	arm-eabi-gcc -nostartfiles -nodefaultlibs -nostdlib -static -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -T../../ecos/TWR-K60D100M_install/lib/target.ld -o "hello_world" $(OBJS) $(USER_OBJS) $(LIBS)
	@echo 'Finished building target: $@'
	@echo ' '

Somehow it does not get passed on to the linker. 

My goal is a simple free platform for my customers to start with. RedBoot, Eclipse, with GDB debugging from Eclipse. Then, they can try before buy, and if they want to use my embedded framework (may or may not end up GPL), they pay for commercial tools with all the wonderful stuff ;-)

But GDB command line is a non-starter for them. So the gap is too big.

I think in general, eCos would benefit from both a good low end tool chain that installs and just works on every platform, and many examples. This is where Freescale MQX does well. They have a free version of Eclipse/Compiler and many starter examples. But, they are very limited on number of platforms. Another problem for me.

Mike


Complete Output
------------------------

07:56:19 **** Incremental Build of configuration Debug for project hello_world ****
make all 
Building file: ../Sources/hello.c
Invoking: Cross GCC Compiler
arm-eabi-gcc -I/home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Wno-write-strings -mcpu=cortex-m3 -mthumb -g -v -ffunction-sections -fdata-sections -fno-exceptions -MMD -MP -MF"Sources/hello.d" -MT"Sources/hello.d" -o "Sources/hello.o" "../Sources/hello.c"
Using built-in specs.
COLLECT_GCC=arm-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/ecos/gnutools/arm-eabi/libexec/gcc/arm-eabi/4.6.3/lto-wrapper
Target: arm-eabi
Configured with: ../../../../src/gcc-4.6.3/configure --target=arm-eabi --with-cpu=arm7tdmi --prefix=/opt/ecos/gnutools/arm-eabi --with-newlib --with-gnu-as --with-gnu-ld --with-gmp=/opt/gmp-4.3.2 --with-mpfr=/opt/mpfr-2.4.2 --with-mpc=/opt/mpc-0.8.2 --enable-languages=c,c++ --enable-threads --disable-hosted-libstdcxx --disable-__cxa_atexit --disable-libquadmath --disable-decimal-float -with-pkgversion='eCos GNU Tools 4.6.3-20120623' --with-bugurl=http://bugs.ecos.sourceware.org/
Thread model: single
gcc version 4.6.3 (eCos GNU Tools 4.6.3-20120623) 
COLLECT_GCC_OPTIONS='-I' '/home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include' '-O2' '-g' '-Wall' '-Wpointer-arith' '-Wstrict-prototypes' '-Wundef' '-Wno-write-strings' '-mcpu=cortex-m3' '-mthumb' '-g' '-v' '-ffunction-sections' '-fdata-sections' '-fno-exceptions' '-MMD' '-MP' '-MF' 'Sources/hello.d' '-MT' 'Sources/hello.d' '-o' 'Sources/hello.o'
/opt/ecos/gnutools/arm-eabi/libexec/gcc/arm-eabi/4.6.3/cc1 -quiet -v -I /home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include -imultilib thumb/thumb2 -MMD Sources/hello.d -MF Sources/hello.d -MP -MT Sources/hello.d -D__USES_INITFINI__ ../Sources/hello.c -quiet -dumpbase hello.c -mcpu=cortex-m3 -mthumb -auxbase hello -g -g -O2 -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Wno-write-strings -version -ffunction-sections -fdata-sections -fno-exceptions -o /tmp/ccPxGVxl.s
GNU C (eCos GNU Tools 4.6.3-20120623) version 4.6.3 (arm-eabi)
	compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/include
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/include-fixed
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/include
End of search list.
GNU C (eCos GNU Tools 4.6.3-20120623) version 4.6.3 (arm-eabi)
	compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1070891678fd12e4083fdb528309ae62
COLLECT_GCC_OPTIONS='-I' '/home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include' '-O2' '-g' '-Wall' '-Wpointer-arith' '-Wstrict-prototypes' '-Wundef' '-Wno-write-strings' '-mcpu=cortex-m3' '-mthumb' '-g' '-v' '-ffunction-sections' '-fdata-sections' '-fno-exceptions' '-MMD' '-MP' '-MF' 'Sources/hello.d' '-MT' 'Sources/hello.d' '-o' 'Sources/hello.o'
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/as -v -I /home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include -mcpu=cortex-m3 -meabi=5 -o /tmp/ccMUDB6x.o /tmp/ccPxGVxl.s
GNU assembler version 2.22 (arm-eabi) using BFD version (eCos GNU Tools 4.6.3-20120623) 2.22
COMPILER_PATH=/opt/ecos/gnutools/arm-eabi/libexec/gcc/arm-eabi/4.6.3/:/opt/ecos/gnutools/arm-eabi/libexec/gcc/arm-eabi/4.6.3/:/opt/ecos/gnutools/arm-eabi/libexec/gcc/arm-eabi/:/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/:/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/:/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/
LIBRARY_PATH=/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/thumb/thumb2/:/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/lib/thumb/thumb2/:/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/:/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/lib/
COLLECT_GCC_OPTIONS='-I' '/home/mike/Embedded/Freescale/ecos/TWR-K60D100M_install/include' '-O2' '-g' '-Wall' '-Wpointer-arith' '-Wstrict-prototypes' '-Wundef' '-Wno-write-strings' '-mcpu=cortex-m3' '-mthumb' '-g' '-v' '-ffunction-sections' '-fdata-sections' '-fno-exceptions' '-MMD' '-MP' '-MF' 'Sources/hello.d' '-MT' 'Sources/hello.d' '-o' 'Sources/hello.o'
/opt/ecos/gnutools/arm-eabi/libexec/gcc/arm-eabi/4.6.3/collect2 -X -o Sources/hello.o /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/thumb/thumb2/crti.o /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/thumb/thumb2/crtbegin.o crt0.o -L/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/thumb/thumb2 -L/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/lib/thumb/thumb2 -L/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3 -L/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/lib /tmp/ccMUDB6x.o --start-group -lgcc -lg -lc --end-group /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/thumb/thumb2/crtend.o /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/thumb/thumb2/crtn.o
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lg
/opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [Sources/hello.o] Error 1

07:56:20 Build Finished (took 929ms)


On Dec 20, 2012, at 1:31 AM, John Dallaway <john@dallaway.org.uk> wrote:

> Mike
> 
> On 20/12/12 07:44, Michael Jones wrote:
> 
>> I have been trying to make an Eclipse/CDT (Juno) project for eCos, but not a
>> Makefile project. Mainly so that it can navigate to h files, and try to see
>> if it will drive GDB.
>> 
>> Eclipse seems to ignore linker options and do its own thing. For example, for
>> the linker I have:
>> 
>> -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -T../../ecos/TWR-K60D100M_install/lib/target.ld
>> 
>> But, it appears that some options, like -T are ignored. And the linker tries
>> to link in crt0.o, even if I set the compile options to not include startup
>> files.
> 
> You are missing the -L linker option specifying the library search path
> (location of libtarget.a). Try modifying your command line as follows:
> 
>> -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -Ttarget.ld
> 
> I hope this helps...
> 
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Eclipse / CDT without Makefile Project

[John Dallaway]

Mike

On 20/12/12 15:15, Michael Jones wrote:

> Thanks, now it is closer. I have provided the output showing the final failure:
> 
> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lg
> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lc
> collect2: ld returned 1 exit status
> make: *** [Sources/hello.o] Error 1
> 
> 07:56:20 Build Finished (took 929ms)
> 
> What is interesting is that even with the -L option, it does not show up in the compile output.
> 
> The rule it makes in the makefile is
> 
> hello_world: $(OBJS) $(USER_OBJS)
> 	@echo 'Building target: $@'
> 	@echo 'Invoking: Cross GCC Linker'
> 	arm-eabi-gcc -nostartfiles -nodefaultlibs -nostdlib -static -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -T../../ecos/TWR-K60D100M_install/lib/target.ld -o "hello_world" $(OBJS) $(USER_OBJS) $(LIBS)
> 	@echo 'Finished building target: $@'
> 	@echo ' '
> 
> Somehow it does not get passed on to the linker.

I believe your build is not getting as far as the above makefile rule.
You are missing the "-c" flag on your _compilation_ line, so GCC is
attempting to both compile and link (using a default linker script) the
first time it is invoked.

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Michael Jones]

John,

So now I am struggling getting GDB to work from Eclipse. It is actually a very interesting problem.

I can load my app from gdb on the command line and run it fine. 

When I load the same app from Eclipse, I get a SIGTRAP at the the reset vector.

reset_vector:

        ldr     sp,=hal_startup_stack
        b       hal_reset_vsr

Stops at the ldr instruction no matter how many times I do a continue.

This is the same problem I had when I was using Insight. That problem was finally diagnosed. When I compiled Insight, it replaced the arm-eabi-gdb file, and when I reverted back to the one from the tool chain, the problem went away.

In this case, I am sure that Eclipse is using the same are-eabi-gdb because I can do a "show version" in the Eclipse command window and get the same revision as the working command line.

There appears to be something very subtle different. As an experiment, I selected my file and loaded my app from the eclipse command line so the GUI was eliminated. I get the same SIGTRAP. And after download, the memory segments are all in the same place.

Do you have any ideas on how to debug this kind of problem? Is it possible that when I use commands like "load" and "cont" what is sent to RedBoot at the other end is different? Could there be hidden communications that change the mode of RedBoot? Could the memory contents after a load be different? Could GDB in the Eclipse environment be inserting some kind of trap like a break point that it is failing to remove when I type "cont"?

I have to admit, I was not so surprised that a newer version of GDB mis-behaved, but I was really surprised that a working version of gdb running in Eclipse would not behave the same.

Mike


On Dec 20, 2012, at 8:34 AM, John Dallaway <john@dallaway.org.uk> wrote:

> Mike
> 
> On 20/12/12 15:15, Michael Jones wrote:
> 
>> Thanks, now it is closer. I have provided the output showing the final failure:
>> 
>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lg
>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lc
>> collect2: ld returned 1 exit status
>> make: *** [Sources/hello.o] Error 1
>> 
>> 07:56:20 Build Finished (took 929ms)
>> 
>> What is interesting is that even with the -L option, it does not show up in the compile output.
>> 
>> The rule it makes in the makefile is
>> 
>> hello_world: $(OBJS) $(USER_OBJS)
>> 	@echo 'Building target: $@'
>> 	@echo 'Invoking: Cross GCC Linker'
>> 	arm-eabi-gcc -nostartfiles -nodefaultlibs -nostdlib -static -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -T../../ecos/TWR-K60D100M_install/lib/target.ld -o "hello_world" $(OBJS) $(USER_OBJS) $(LIBS)
>> 	@echo 'Finished building target: $@'
>> 	@echo ' '
>> 
>> Somehow it does not get passed on to the linker.
> 
> I believe your build is not getting as far as the above makefile rule.
> You are missing the "-c" flag on your _compilation_ line, so GCC is
> attempting to both compile and link (using a default linker script) the
> first time it is invoked.
> 
> I hope this helps...
> 
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Ilija Kocho]

Hi Mike

From my experience I have noticed that when debugging with Redboot, it
is important to supply target file (path) to the invoking GDB command
line. Some Eclipse front ends don't do that. You can try to add target
path to the GDB command (Debug configurations -> Debugger).

Ilija


On 21.12.2012 08:03, Michael Jones wrote:
> John,
>
> So now I am struggling getting GDB to work from Eclipse. It is actually a very interesting problem.
>
> I can load my app from gdb on the command line and run it fine. 
>
> When I load the same app from Eclipse, I get a SIGTRAP at the the reset vector.
>
> reset_vector:
>
>         ldr     sp,=hal_startup_stack
>         b       hal_reset_vsr
>
> Stops at the ldr instruction no matter how many times I do a continue.
>
> This is the same problem I had when I was using Insight. That problem was finally diagnosed. When I compiled Insight, it replaced the arm-eabi-gdb file, and when I reverted back to the one from the tool chain, the problem went away.
>
> In this case, I am sure that Eclipse is using the same are-eabi-gdb because I can do a "show version" in the Eclipse command window and get the same revision as the working command line.
>
> There appears to be something very subtle different. As an experiment, I selected my file and loaded my app from the eclipse command line so the GUI was eliminated. I get the same SIGTRAP. And after download, the memory segments are all in the same place.
>
> Do you have any ideas on how to debug this kind of problem? Is it possible that when I use commands like "load" and "cont" what is sent to RedBoot at the other end is different? Could there be hidden communications that change the mode of RedBoot? Could the memory contents after a load be different? Could GDB in the Eclipse environment be inserting some kind of trap like a break point that it is failing to remove when I type "cont"?
>
> I have to admit, I was not so surprised that a newer version of GDB mis-behaved, but I was really surprised that a working version of gdb running in Eclipse would not behave the same.
>
> Mike
>
>
> On Dec 20, 2012, at 8:34 AM, John Dallaway <john@dallaway.org.uk> wrote:
>
>> Mike
>>
>> On 20/12/12 15:15, Michael Jones wrote:
>>
>>> Thanks, now it is closer. I have provided the output showing the final failure:
>>>
>>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory
>>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lg
>>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lc
>>> collect2: ld returned 1 exit status
>>> make: *** [Sources/hello.o] Error 1
>>>
>>> 07:56:20 Build Finished (took 929ms)
>>>
>>> What is interesting is that even with the -L option, it does not show up in the compile output.
>>>
>>> The rule it makes in the makefile is
>>>
>>> hello_world: $(OBJS) $(USER_OBJS)
>>> 	@echo 'Building target: $@'
>>> 	@echo 'Invoking: Cross GCC Linker'
>>> 	arm-eabi-gcc -nostartfiles -nodefaultlibs -nostdlib -static -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -T../../ecos/TWR-K60D100M_install/lib/target.ld -o "hello_world" $(OBJS) $(USER_OBJS) $(LIBS)
>>> 	@echo 'Finished building target: $@'
>>> 	@echo ' '
>>>
>>> Somehow it does not get passed on to the linker.
>> I believe your build is not getting as far as the above makefile rule.
>> You are missing the "-c" flag on your _compilation_ line, so GCC is
>> attempting to both compile and link (using a default linker script) the
>> first time it is invoked.
>>
>> I hope this helps...
>>
>> John Dallaway
>> eCos maintainer
>> http://www.dallaway.org.uk/john
>>
>> -- 
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Michael Jones]

Ilija,

Wow! That worked. Now I can set breakpoints and run.

I think I am down to one last problem. How do I control where the printf goes? I selected Allocate Console on the Common tab, the the Console in Eclipse only shows:

[Switching to Thread 2]
[New Thread 1]

If I turn that off, I get:

361,985 (gdb) 
362,026 @"Hello Mike.\n"
362,030 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x1fff\
e4de",func="main",file="../Sources/hello.c",fullname="/home/mike/Embedded/Freescale/app/hello_world/\
Sources/hello.c",line="46",times="1",original-location="/home/mike/Embedded/Freescale/app/hello_worl\
d/Sources/hello.c:46"}

I am not sure if the @"Hello Mike.\n" is output or just information. I assume it is output because it does not show printf.

Can you give some pointers on how to get a console that is only for input/output?

I would prefer a console that sends the data over the ethernet cable I am using with RedBoot and not try to use RS232 or USB. This way I could debug a target remotely.

Also, do you know a way to reset the target without a reset button on the Tower? If I was remote, I may not have a way to use the button. When my app exits, it seems to leave RedBoot in a hung state.

Mike

On Dec 22, 2012, at 9:50 AM, Ilija Kocho <ilijak@siva.com.mk> wrote:

> On 22.12.2012 17:07, Michael Jones wrote:
>> Iligja,
>> 
>> Hm, I am using a Debug Configuration of type GDB Hardware Debugging. There is no target path like traditional projects, but instead has a Remote Target section where you put in the IP and Port.
> 
> In Debug tab find GDB Command: It probably contains the path to your GDB
> something like: /home/opt/ecos/gnutools/arm-eabi/bin/arm-eabi-gdb
> 
> Just add your target ELF file like you would do in command line
> (probably you need to supply complete path):
> /opt/ecos/gnutools/arm-eabi/bin/arm-eabi-gdb <your_elf_file>
> 
> It works for me, I hope it will work for you.
> 
> Ilija


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Ilija Kocho]

Hi Mike

My insight in Eclipse is limited so I hope somebody else will hint us
how to get the console I/O.

Regarding the target issues, see my comment below. Here I will only say
that for with respect to Redboot this is a small memory system and the
application size is limited. That is the reason why I didn't provide RAM
startup for systems without external memory.

Ilija

On 23.12.2012 00:08, Michael Jones wrote:
> I noticed a few things, and did not copy the list because it might be Kinetis specific. See compilation problems towards the end.
>
> I setup a program like this:
>
>     int integer1, integer2, sum;
>
>     printf("Hello Mike.\n");
>
>     printf("Enter first integer:\n");
>     scanf("%d", &integer1);
>     return 0;
>
> And when run, in the Eclipse gdb console (I finally realized there is more than one console):
>
> 947,145 (gdb) 
> 947,415 *running,thread-id="all"
> 947,457 @"Hello Mike.\n"
> 947,460 @"Enter first integer:\n"
>
> Suggests it got some printf data, but it did not appear on the app console.
>
> Then on the app console, I type 45 and on the gdb console get:
>
> 192,289 27-interpreter-exec console 45
>
> I don't know if this means gdb sent 45 to RedBoot or not. I assume so. But the application did not respond. So tty problems are in both directions. I can't tell what is gdb and what is RedBoot.
>
> I extend the program like this:
>
>     int integer1, integer2, sum;
>
>     printf("Hello Mike.\n");
>
>     printf("Enter first integer:\n");
>     scanf("%d", &integer1);
>     printf("Enter second integer:\n");
>     scanf("%d", &integer2);
>     sum = integer1 + integer2;
>
> And I run from command line gdb (not Eclipse) which does print the one line Hello Mike app. I get:
>
> (gdb) cont
> Continuing.
> FLASH configuration checksum error or invalid key
> ASSERT FAIL: <2>stream.cxx[603]virtual Cyg_ErrNo Cyg_StdioStream::write() Stream object is not a valid stream!
> ASSERT FAIL: <2>stream.cxx          [ 603] virtual Cyg_ErrNo Cyg_StdioStream::write()                                                           Stream object is not a valid stream!
>
> So things are not so well with the command line gdb either.
>
> I then tried another experiment with a program like this:
>
>     int integer1, integer2, sum;
>
>     printf("Hello Mike.\n");
>
>     printf("Enter first integer:\n");
>     scanf("%d", &integer1);
>     printf("Enter second integer:\n");
>     scanf("%d", &integer2);
>     sum = integer1 + integer2;
>     printf("Sum is %d\n", sum);
>     return 0;
>
> And I get a compile error:
>
> Description	Resource	Path	Location	Type
> address 0x200106fc of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
> address 0x20010704 of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>
> So something is also not right with the compilation either.

Compilation is probably OK, but linker complains because there is not
enough memory.
This makes me to suspect that previous errors are due to low memory,
probably some stack overflow.

The linker will include only used functions so if you scanf() it will
add couple of tens KB to the image. You can save some memory if you
configure printf()/scanf() without floating point support

>
> Now, I backed off to just printf programs with multiple lines to see what can be done.
>
> A 10 line printf compiles and runs.
> A 10 count for loop with printf works.
>
> So it does not appear that the number of lines in the program matters.
>
> I change the sum program to only printf and it can add numbers and print (gdb command line, not Eclipse)
>
> With some playing around, the scanf seems to cause the compiler error about regions.
>
> So I think try:
>
>    c = getchar();
>
> And with the command line gdb it prints, then hangs, and typing a character does not let the program proceed. So this seems like even with the command line arm-eabi-gdb, console input may not be routed back through RedBoot to the application.
>
> With the example redboot and application projects you sent, are you able to read from stdin?
>
> Do you know how to get Eclipse to handle IO for gdb?

I have the same problem with Eclipse.
But I usually activate the (real) serial device driver and I get I/O on
serial port.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Michael Jones]

Ilija,

What I am doing with MQX is debugging from Flash. If I use a PEMicro JTAG debugger, it is pretty fast to load 128K. My app does not use a lot of memory, so I have not run out of RAM.

If I finally get a JTAG debugger, can I do the same with eCos? That is, debug from Flash?

Mike

On Dec 22, 2012, at 5:09 PM, Ilija Kocho <ilijak@siva.com.mk> wrote:

> Hi Mike
> 
> My insight in Eclipse is limited so I hope somebody else will hint us
> how to get the console I/O.
> 
> Regarding the target issues, see my comment below. Here I will only say
> that for with respect to Redboot this is a small memory system and the
> application size is limited. That is the reason why I didn't provide RAM
> startup for systems without external memory.
> 
> Ilija
> 
> On 23.12.2012 00:08, Michael Jones wrote:
>> I noticed a few things, and did not copy the list because it might be Kinetis specific. See compilation problems towards the end.
>> 
>> I setup a program like this:
>> 
>>    int integer1, integer2, sum;
>> 
>>    printf("Hello Mike.\n");
>> 
>>    printf("Enter first integer:\n");
>>    scanf("%d", &integer1);
>>    return 0;
>> 
>> And when run, in the Eclipse gdb console (I finally realized there is more than one console):
>> 
>> 947,145 (gdb) 
>> 947,415 *running,thread-id="all"
>> 947,457 @"Hello Mike.\n"
>> 947,460 @"Enter first integer:\n"
>> 
>> Suggests it got some printf data, but it did not appear on the app console.
>> 
>> Then on the app console, I type 45 and on the gdb console get:
>> 
>> 192,289 27-interpreter-exec console 45
>> 
>> I don't know if this means gdb sent 45 to RedBoot or not. I assume so. But the application did not respond. So tty problems are in both directions. I can't tell what is gdb and what is RedBoot.
>> 
>> I extend the program like this:
>> 
>>    int integer1, integer2, sum;
>> 
>>    printf("Hello Mike.\n");
>> 
>>    printf("Enter first integer:\n");
>>    scanf("%d", &integer1);
>>    printf("Enter second integer:\n");
>>    scanf("%d", &integer2);
>>    sum = integer1 + integer2;
>> 
>> And I run from command line gdb (not Eclipse) which does print the one line Hello Mike app. I get:
>> 
>> (gdb) cont
>> Continuing.
>> FLASH configuration checksum error or invalid key
>> ASSERT FAIL: <2>stream.cxx[603]virtual Cyg_ErrNo Cyg_StdioStream::write() Stream object is not a valid stream!
>> ASSERT FAIL: <2>stream.cxx          [ 603] virtual Cyg_ErrNo Cyg_StdioStream::write()                                                           Stream object is not a valid stream!
>> 
>> So things are not so well with the command line gdb either.
>> 
>> I then tried another experiment with a program like this:
>> 
>>    int integer1, integer2, sum;
>> 
>>    printf("Hello Mike.\n");
>> 
>>    printf("Enter first integer:\n");
>>    scanf("%d", &integer1);
>>    printf("Enter second integer:\n");
>>    scanf("%d", &integer2);
>>    sum = integer1 + integer2;
>>    printf("Sum is %d\n", sum);
>>    return 0;
>> 
>> And I get a compile error:
>> 
>> Description	Resource	Path	Location	Type
>> address 0x200106fc of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>> address 0x20010704 of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>> 
>> So something is also not right with the compilation either.
> 
> Compilation is probably OK, but linker complains because there is not
> enough memory.
> This makes me to suspect that previous errors are due to low memory,
> probably some stack overflow.
> 
> The linker will include only used functions so if you scanf() it will
> add couple of tens KB to the image. You can save some memory if you
> configure printf()/scanf() without floating point support
> 
>> 
>> Now, I backed off to just printf programs with multiple lines to see what can be done.
>> 
>> A 10 line printf compiles and runs.
>> A 10 count for loop with printf works.
>> 
>> So it does not appear that the number of lines in the program matters.
>> 
>> I change the sum program to only printf and it can add numbers and print (gdb command line, not Eclipse)
>> 
>> With some playing around, the scanf seems to cause the compiler error about regions.
>> 
>> So I think try:
>> 
>>   c = getchar();
>> 
>> And with the command line gdb it prints, then hangs, and typing a character does not let the program proceed. So this seems like even with the command line arm-eabi-gdb, console input may not be routed back through RedBoot to the application.
>> 
>> With the example redboot and application projects you sent, are you able to read from stdin?
>> 
>> Do you know how to get Eclipse to handle IO for gdb?
> 
> I have the same problem with Eclipse.
> But I usually activate the (real) serial device driver and I get I/O on
> serial port.
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Eclipse / CDT without Makefile Project

[Ilija Kocho]

On 23.12.2012 01:19, Michael Jones wrote:
> Ilija,
>
> What I am doing with MQX is debugging from Flash. If I use a PEMicro JTAG debugger, it is pretty fast to load 128K. My app does not use a lot of memory, so I have not run out of RAM.
>
> If I finally get a JTAG debugger, can I do the same with eCos? That is, debug from Flash?

Sure. ROM startup builds Flash image. I would expect any JTAG interface
supporting Kinetis flashing and providing GDB server to do the job.

Ilija

>
> Mike
>
> On Dec 22, 2012, at 5:09 PM, Ilija Kocho <ilijak@siva.com.mk> wrote:
>
>> Hi Mike
>>
>> My insight in Eclipse is limited so I hope somebody else will hint us
>> how to get the console I/O.
>>
>> Regarding the target issues, see my comment below. Here I will only say
>> that for with respect to Redboot this is a small memory system and the
>> application size is limited. That is the reason why I didn't provide RAM
>> startup for systems without external memory.
>>
>> Ilija
>>
>> On 23.12.2012 00:08, Michael Jones wrote:
>>> I noticed a few things, and did not copy the list because it might be Kinetis specific. See compilation problems towards the end.
>>>
>>> I setup a program like this:
>>>
>>>    int integer1, integer2, sum;
>>>
>>>    printf("Hello Mike.\n");
>>>
>>>    printf("Enter first integer:\n");
>>>    scanf("%d", &integer1);
>>>    return 0;
>>>
>>> And when run, in the Eclipse gdb console (I finally realized there is more than one console):
>>>
>>> 947,145 (gdb) 
>>> 947,415 *running,thread-id="all"
>>> 947,457 @"Hello Mike.\n"
>>> 947,460 @"Enter first integer:\n"
>>>
>>> Suggests it got some printf data, but it did not appear on the app console.
>>>
>>> Then on the app console, I type 45 and on the gdb console get:
>>>
>>> 192,289 27-interpreter-exec console 45
>>>
>>> I don't know if this means gdb sent 45 to RedBoot or not. I assume so. But the application did not respond. So tty problems are in both directions. I can't tell what is gdb and what is RedBoot.
>>>
>>> I extend the program like this:
>>>
>>>    int integer1, integer2, sum;
>>>
>>>    printf("Hello Mike.\n");
>>>
>>>    printf("Enter first integer:\n");
>>>    scanf("%d", &integer1);
>>>    printf("Enter second integer:\n");
>>>    scanf("%d", &integer2);
>>>    sum = integer1 + integer2;
>>>
>>> And I run from command line gdb (not Eclipse) which does print the one line Hello Mike app. I get:
>>>
>>> (gdb) cont
>>> Continuing.
>>> FLASH configuration checksum error or invalid key
>>> ASSERT FAIL: <2>stream.cxx[603]virtual Cyg_ErrNo Cyg_StdioStream::write() Stream object is not a valid stream!
>>> ASSERT FAIL: <2>stream.cxx          [ 603] virtual Cyg_ErrNo Cyg_StdioStream::write()                                                           Stream object is not a valid stream!
>>>
>>> So things are not so well with the command line gdb either.
>>>
>>> I then tried another experiment with a program like this:
>>>
>>>    int integer1, integer2, sum;
>>>
>>>    printf("Hello Mike.\n");
>>>
>>>    printf("Enter first integer:\n");
>>>    scanf("%d", &integer1);
>>>    printf("Enter second integer:\n");
>>>    scanf("%d", &integer2);
>>>    sum = integer1 + integer2;
>>>    printf("Sum is %d\n", sum);
>>>    return 0;
>>>
>>> And I get a compile error:
>>>
>>> Description	Resource	Path	Location	Type
>>> address 0x200106fc of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>>> address 0x20010704 of hello_world section `.bss' is not within region `ram'	hello_world		 	C/C++ Problem
>>>
>>> So something is also not right with the compilation either.
>> Compilation is probably OK, but linker complains because there is not
>> enough memory.
>> This makes me to suspect that previous errors are due to low memory,
>> probably some stack overflow.
>>
>> The linker will include only used functions so if you scanf() it will
>> add couple of tens KB to the image. You can save some memory if you
>> configure printf()/scanf() without floating point support
>>
>>> Now, I backed off to just printf programs with multiple lines to see what can be done.
>>>
>>> A 10 line printf compiles and runs.
>>> A 10 count for loop with printf works.
>>>
>>> So it does not appear that the number of lines in the program matters.
>>>
>>> I change the sum program to only printf and it can add numbers and print (gdb command line, not Eclipse)
>>>
>>> With some playing around, the scanf seems to cause the compiler error about regions.
>>>
>>> So I think try:
>>>
>>>   c = getchar();
>>>
>>> And with the command line gdb it prints, then hangs, and typing a character does not let the program proceed. So this seems like even with the command line arm-eabi-gdb, console input may not be routed back through RedBoot to the application.
>>>
>>> With the example redboot and application projects you sent, are you able to read from stdin?
>>>
>>> Do you know how to get Eclipse to handle IO for gdb?
>> I have the same problem with Eclipse.
>> But I usually activate the (real) serial device driver and I get I/O on
>> serial port.
>>
>>
>> -- 
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss