EmbDev.net

Forum: ARM programming with GCC/GNU tools building lwip FreeRTOS 7x256 example error


Author: hotislandn (Guest)
Posted on:

Rate this post
0 useful
not useful
there is a demo in the free rtos folder , named   lwIP_Demo_Rowley_ARM7
but when make , the outputs are:

-Xlinker -ortosdemo.elf -Xlinker -M -Xlinker -Map=rtosdemo.map
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(freer.o):
In function `_mall
oc_trim_r':mallocr.c:(.text+0x48): undefined reference to `_sbrk_r'
:mallocr.c:(.text+0x64): undefined reference to `_sbrk_r'
:mallocr.c:(.text+0x84): undefined reference to `_sbrk_r'
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(makebuf.o):
In function `__s
makebuf':makebuf.c:(.text+0x3c): undefined reference to `_fstat_r'
:makebuf.c:(.text+0x110): undefined reference to `isatty'
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(mallocr.o):
In function `_ma
lloc_r':mallocr.c:(.text+0x40c): undefined reference to `_sbrk_r'
:mallocr.c:(.text+0x4b4): undefined reference to `_sbrk_r'
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(stdio.o):
In function `__scl
ose':stdio.c:(.text+0x10): undefined reference to `_close_r'
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(stdio.o):
In function `__sse
ek':stdio.c:(.text+0x3c): undefined reference to `_lseek_r'
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(stdio.o):
In function `__swr
ite':stdio.c:(.text+0x94): undefined reference to `_lseek_r'
:stdio.c:(.text+0xb8): undefined reference to `_write_r'
d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(stdio.o):
In function `__sre
ad':stdio.c:(.text+0xe4): undefined reference to `_read_r'
collect2: ld returned 1 exit status
gmake: *** [rtosdemo.elf] Error 1


It seems the low level functions for the libc.a is not defined , how can
it works?
Thanks!

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
hotislandn wrote:
> there is a demo in the free rtos folder , named   lwIP_Demo_Rowley_ARM7
> but when make , the outputs are:
>
> -Xlinker -ortosdemo.elf -Xlinker -M -Xlinker -Map=rtosdemo.map
> d:/_dsetup/arm/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/l 
ib/interwork\libc.a(freer.o):
> In function `_mall
> oc_trim_r':mallocr.c:(.text+0x48): undefined reference to `_sbrk_r'
> :mallocr.c:(.text+0x64): undefined reference to `_sbrk_r'
> :mallocr.c:(.text+0x84): undefined reference to `_sbrk_r'
>...
>
> It seems the low level functions for the libc.a is not defined , how can
> it works?

The newlib (libc) needs interface-functions to the hardware: system
calls or syscalls. Please use the search-function of the forum. It's a
FAQ.

Martin Thomas

Author: hotislandn (Guest)
Posted on:

Rate this post
0 useful
not useful
Got it.Thanks!
Suggest add that syscalls file to this example.
Hence there a 7x256-Ek in hand,this example will be tested.

Author: Jon Newcomb (jnewcomb)
Posted on:

Rate this post
0 useful
not useful
Following on from this thread, I copied over syscalls.c from the
AT91SAM7S-BasicUSB example, updated the make file and am struggling with
more errors..

The first problem I ran into was:
syscalls.c: In function 'my_putc':
syscalls.c:21: warning: implicit declaration of function
'AT91F_US_TxReady'
syscalls.c:22: warning: implicit declaration of function
'AT91F_US_PutChar'
syscalls.c: In function 'my_kbhit':
syscalls.c:27: warning: implicit declaration of function
'AT91F_US_RxReady'
syscalls.c: In function 'my_getc':
syscalls.c:33: warning: implicit declaration of function
'AT91F_US_GetChar'
... and lots of unused parameter warnings
(Followed by a link error)
syscalls.o: In function `my_putc':syscalls.c:(.text+0x60): undefined
reference to `AT91F_US_TxReady'
:syscalls.c:(.text+0x74): undefined reference to `AT91F_US_PutChar'
syscalls.o: In function `_read_r':syscalls.c:(.text+0xe0): undefined
reference to `AT91F_US_RxReady'
:syscalls.c:(.text+0x118): undefined reference to `AT91F_US_GetChar'

This is because there are two headers "lib_AT91SAM7X256.h" and
"ioAT91SAM7X256.h". They are quite similar.

Not sure which to use..? lib_AT91SAM7X256.h contains declaration of
AT91F_US_TxReady and others - but generates more compile errors when I
try and use it, starting off with..

../FreeRTOS/Source/portable/GCC/ARM7_AT91SAM7S/lib_AT91SAM7X256.h:60:28:
error: macro "AT91F_AIC_ConfigureIt" passed 5
arguments, but takes just 4

..... and opens a new can of worms!

When I read this posting:
http://en.mikrocontroller.net/topic/67145
I can't help think I missed something. Does anyone have step by step
instruction on how to get this to work?

Here is a list of resources I used..

Extract from WinARM help (Relevant to AT91):
To use functions from stdio (printf et al) in own projects
interface-functions for the newlib have to be provided (System
Calls/"syscalls", i.e. sbrk, see chapter 11 in doc/libc.pdf).
The examples lpc2129_adc_stdio and at91sam7s64_Hello show how the
system-calls can be implemented without an additional library
(source-files syscalls.c)

Much of my confusion stems from having similar header files of differing
revisions in the -
 + Demo directory of FreeRTOS
 + Example directory in WinARM
 + Port specific directory of
.\FreeRTOS\Source\portable\GCC\ARM7_AT91SAM7S

Also a background off IAR EW means I don

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
> This is because there are two headers "lib_AT91SAM7X256.h" and
> "ioAT91SAM7X256.h". They are quite similar.
> Not sure which to use..?

I have not read the X256 examples so far but from the Atmel-sources I
know for the AT91SAM7S64 the ioAT*.h is are the register-defintions for
the IAR-compiler. For gcc I use the file AT91*.h. So for AT91SAM7S64
it's AT91SAM7S64.h and not ioAT91SAM7S64.h, it might be similar for the
7X.

> lib_AT91SAM7X256.h contains declaration of
> AT91F_US_TxReady and others - but generates more compile errors when I
> try and use it, starting off with..

The lib*.h-files are different. They define some simple inline-functions
to make hardware-access a little easier. Make sure to define the
__inline before including this header-file (I use #define __inline
static inline). Include the register-definitions before including the
lib*.h. From one of the Atmel-examples from the WinARM-collection:

#include "AT91SAM7S64.h"
#define __inline static inline
#include "lib_AT91SAM7S64.h"

Try to use the same order with the files for the 7X. I hope that I will
receive a board with a SAM7X soon. If I have some time I will provide
(ported) examples in the WinARM example-collection for this target.

> ../FreeRTOS/Source/portable/GCC/ARM7_AT91SAM7S/lib_AT91SAM7X256.h:60:28:
> error: macro "AT91F_AIC_ConfigureIt" passed 5
> arguments, but takes just 4
>
> ..... and opens a new can of worms!

Try to recompile with the "include-order" mentioned above.

> When I read this posting:
> http://en.mikrocontroller.net/topic/67145
> I can't help think I missed something. Does anyone have step by step
> instruction on how to get this to work?
>
> Here is a list of resources I used..
>
> Extract from WinARM help (Relevant to AT91):

Oh, it's not a "help", it's just a small collection of information from
which I think that they might be useful or answers to FAQ I've got by
e-mail.

> To use functions from stdio (printf et al) in own projects
> interface-functions for the newlib have to be provided (System
> Calls/"syscalls", i.e. sbrk, see chapter 11 in doc/libc.pdf).
> The examples lpc2129_adc_stdio and at91sam7s64_Hello show how the
> system-calls can be implemented without an additional library
> (source-files syscalls.c)
>
> Much of my confusion stems from having similar header files of differing
> revisions in the -
>  + Demo directory of FreeRTOS
>  + Example directory in WinARM
>  + Port specific directory of
> .\FreeRTOS\Source\portable\GCC\ARM7_AT91SAM7S

Try to use the include files which come with the source first since the
developer of the code used them for testing. If it does not work you can
try to replace the files with those from the newest Atmel "kit-examples"
but you might have to port some code.

> Also a background off IAR EW means I don

Author: Jon Newcomb (jnewcomb)
Posted on:

Rate this post
0 useful
not useful
Thanks, that's got me going again..
I'm in the process of getting the 'common' examples provided with
FreeRTOS working using WinARM on the AT91SAM7S64. I am doing this by
'stripping down' the lwIP example and using a WinAVR example style
makefile and syscalls.c. Hope to pass it your way depending on how far I
get. If anyone (else!) is struggling with this, I can send you what I
have so far. My email is:
arm@jnewcomb_NoSPHAM_.com

I'm using one of these, check out the price of the module, eval kits and
JTAG debugger; you can't go far wrong!
http://www.propox.com/products/t_137.html

Jon.

Author: Jim Kaz (ancaritha)
Posted on:

Rate this post
0 useful
not useful
I've gotten all the errors tha have been presented on this page, and
using the advice presented I've been able to get rid of all of them
(thanks!) except for one (doh!).

My final error is:

Linking: .out/ARMUSB.elf
arm-elf-gcc  -mcpu=arm7tdmi  -I. -gdwarf-2 -DROM_RUN -DVECTORS_ROM   -O1
-Wall -
Wcast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type
 -Wshadow -Wunused  -MD -MP -MF .dep/ARMUSB.elf.d .out/SAM7A3Assembly.o
.out/SA
M7Ainit.o .out/main.o .out/hid_enumerate.o .out/dbgu.o
.out/WinARMsyscalls.o
 --output .out/ARMUSB.elf -nostartfiles -Wl,-Map=.out/ARMUSB.map,--cref
-lc  -lm
 -lc -lgcc  -lstdc++
-T../../../../Root/Builds/BuildComps/ArmResources/AT91SAM7A
3-ROM.ld

c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libc.a(ex 
it.o):
I
n function `exit':exit.c:(.text+0x28): undefined reference to `_exit'
collect2: ld returned 1 exit status
make: *** [.out/ARMUSB.elf] Error 1


I noticed in the syscalls.c example provided with the 7SUSB example that
the _exit function is in an #ifdef 0.  I removed this, but it still made
my linker sad, so I put it back.

I'm porting example IAR code for the new SAM7A3 eval board over to
WinARM.


My apologies if this has been answered somewhere else.  I did some
searching on the forum and wasn't able to find it, but it doesn't mean
its not already there.

Thanks

Author: Stefan (Guest)
Posted on:

Rate this post
0 useful
not useful
I have seen exit in the startup code. Maybe it is expected to be startup
code and therefor the #if 0... but your startup code hasn't this code.

Look for something like that in startup.S or whatever the name of your
startup code is and add the last lines or write a function with _exit.

// ---------------------------- snip -----------------------------
  // ##################################################
  // Branch on C code main function (with interworking)
  // ##################################################
  .global main                    // int main(void)
  ldr r0, =main      // __main
  bx r0

  .size   _start, . - _start
  .endfunc

//
// The function main() should be a closed loop and should not return.
//
      .global _reset, reset, exit, abort
      .func   _reset
_reset:
reset:
exit:
abort:
      b     .                         // loop until reset

      .size _reset, . - _reset
  .endfunc
.end
// ---------------------------- snip -----------------------------

Author: Jim Kaz (ancaritha)
Posted on:

Rate this post
0 useful
not useful
Got it!  Thanks Stefan!

Now its off to the Gods of Google to find out the compiler flags I need
to get gcc to compile a .bin file so I can actually program my eval
board :)

Author: Jim Kaz (ancaritha)
Posted on:

Rate this post
0 useful
not useful
Holy mother of god the map file is huge with all the newlib stuff in it!
The one from the IAR compiler was 27k, this one is 97k.  I know atleast
some of that will be because IAR is optimized for Atmel and GCC is not
optimized because it has to be used by everyone but damn...  I'm still
adjusting the makefile to spit out a .bin file instead of .hex, but the
IAR's bin file was 3k, and the GCC hex file was 127k.  Different between
.bin and .hex?  I dunno, but 124k is a lot either way.

Author: Jim Kaz (ancaritha)
Posted on:

Rate this post
0 useful
not useful
Couldn't find a way to edit previous posts, so this makes post number 3
in a row, sorry!

Figured out how to make the .bin file.  Its 45.4K in size... still seems
like a lot considerin the IAR one was 3K...

Author: Jon Newcomb (jnewcomb)
Posted on:

Rate this post
0 useful
not useful
Sounds like we need some code...
http://www.jnewcomb.com/share/TheStorySoFar.zip

Completely untested on real hardware, but hay, it compiles without any
errors under WinARM. Wahay!

You will have to check the paths in the makefile. Check out the giff for
locations of the FreeRTOS directory in relation to the working
directory.

One thing that niggles me is the fact that UART routines in the FreeRTOS
example dir (ARM7_AT91FR40008_GCC) have lots of 'critical' sections
where interrupts are disabled. My syscalls.c seems to just fire stuff at
the hardware.. anyone got ideas as to where to go next, I'm all ears.

In response to your last question, here is the last part of the build.
map file is also in the provided zip file.
main.elf  :
section            size      addr
startup              68   1048576
prog              33848   1048644
.data              2092   2097152
.bss              24428   2099244
.debug_abbrev      3134         0
.debug_info       18327         0
.debug_line        4542         0
.debug_frame       2968         0
.debug_loc         4133         0
.debug_pubnames    1515         0
.debug_aranges      680         0
.debug_str          533         0
.comment           1161         0
Total             97429

PS, if anyone wants to look at the map file and say 'that will NEVER
work because ...', you would be doing me a favour.

Jon Newcomb.

Author: Otto Mageschke (fink)
Posted on:

Rate this post
0 useful
not useful
Hallo,
Since some days I own the AT91SAM7X-EK. I want shortly report how to
built the FreeRTOS demo "lwIP_Demo_Rowley_ARM7" for this
evaluationboard, because I had the same probs like threadopener
hotislandn.

1.  WinARM-20060606.exe unzip to C:\
2.  FreeRTOSV4.0.3.zip unzip to C:\
3.  Copy directory C:\FreeRTOS\Demo\lwIP_Demo_Rowley_ARM7 to
C:\WinARM\examples\FreeRTOS_4_0_2\Demo\lwIP_Demo_Rowley_ARM7
4.  Copy file
C:\WinARM\examples\at91sam7s64_basicusb\AT91SAM7S-BasicUSB\src\syscalls. 
c
to
C:\WinARM\examples\FreeRTOS_4_0_2\Demo\lwIP_Demo_Rowley_ARM7\syscalls.c
5.  Edit file
C:\WinARM\examples\FreeRTOS_4_0_2\Demo\lwIP_Demo_Rowley_ARM7\syscalls.c
:
  Insert after line "#include "Board.h"" following two lines:
  #define __inline static inline
  #include "lib_AT91SAM7X256.h"


6. The macro "AT91F_AIC_ConfigureIt" is defined twice: in AT91SAM7X256.h
and in lib_AT91SAM7X256.h
One has comment out the complete macrodefinition at the end of the file:
C:\WinARM\examples\FreeRTOS_4_0_2\Source\portable\GCC\ARM7_AT91SAM7S\AT9 
1SAM7X256.h
"#define AT91F_AIC_ConfigureIt( irq_id, priority, src_type, newHandler
)" , (14 lines at all)
7. Edit the makefile
C:\WinARM\examples\FreeRTOS_4_0_2\Demo\lwIP_Demo_Rowley_ARM7\makefile :

The line "syscalls.c" with '\' after port.c has to be inserted:

#
# Source files that can be built to THUMB mode.
#
FREERTOS_THUMB_SRC= \
  ../../Source/tasks.c \
  ../../Source/queue.c \
  ../../Source/list.c \
  ../../Source/portable/GCC/ARM7_AT91SAM7S/port.c \
  syscalls.c

8. call make, rtosdemo.bin will be created.

9. I load the binfile with SAM-BA into the board. Don't forget to
execute the script "Boot from flash (GPNVM2). On next power-on the
webserver ist running.

I tried the steps on a virgin installation. Hope it help's.
Many thanks to the others, they helped me a lot.

Sven Koop

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
Sven Koop wrote:
> ...

Thanks for this detailled description.

I might be a good idea to e-mail this to Richard Barry from
FreeRTOS.org. Maybe he will include a "non-IDE" arm-elf version of his
7X-example in the next version of FreeRTOS.

Martin Thomas

Author: Otto Mageschke (fink)
Posted on:

Rate this post
0 useful
not useful
Sorry, there was an error in my posting above.

The problem is: there is an macro "AT91F_AIC_ConfigureIt" in
AT91SAM7X256.h and an function with the same name in lib_AT91SAM7X256.h.
I solved the problem in the following way: (replace point 6. in my
posting above with following)

6. In
C:\WinARM\examples\FreeRTOS_4_0_2\Source\portable\GCC\ARM7_AT91SAM7S\lib 
_AT91SAM7X256.h
the function prototype  "AT91F_AIC_ConfigureIt" has to be renamed in
"AT91F_AIC_ConfigureItH" (line 55) and the one and only call of this
function in line 197 (in function  "AT91F_AIC_Open") has to be correct
in "AT91F_AIC_ConfigureItH".

This workaround works fine for me. I allways compile all files with
"make clean" and "make", because the makefile does not watch for all
headerfiles.

Sven Koop

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.