# Forum: ARM programming with GCC/GNU tools Problem with FreeRTOS port and AT91SAM7S256

 Author: Scott K. (skirkpatrick) Posted on: 2006-11-08 18:27

Rate this post
 0 ▲ useful ▼ not useful
This is mostly directed toward Martin Thomas but anybody else who can
help me is more than welcome!

I'm using the FreeRTOS port from
http://gandalf.arubi.uni-kl.de/avr_projects/arm_pr...
with the YARGARTO toolset and Jim Lynch's tutorial on an Olimex
SAM7-P256 eval board.  I've changed the board.h file for my LED's and
removed all the tasks creation calls except the check task and changed
it so that it doesn't check the other tasks.  This should simply give me

When I build it and flash it, it runs as expected.  I can use OpenOCD
and Eclipse and I can use the debugger to set breakpoints and step
through the code.  However, I do have a few problems.  If I change the
makefile so that optimizations are turned off (versus optimized for
size), the resulting build (after doing a "make clean") will not run
after flashing.  Also, I can't to stop at "main" as a breakpoint.

The other problem is getting it to run in RAM.  If I leave it optimized
for size but change RUN_MODE to RAM_RUN, I get a compiler error in
startup_SAM7S.s about the __ctor labels.  If I comment out then entire
section on __ctor initialization, it builds fine.  However, after I load
it with GDB, I can't get a break on "main" again.  I am manually
remapping RAM to location 0x00 in GDB and I noticed that there is a
remap section in startup_SAM7S.s that is compiled if RAM_RUN is set,
which I've commented out temporarily.

So why is it that an unoptimized flash build doesn't work and I can't
seem to get a RAM build to work?

 Author: Michael F. (mifi) Posted on: 2006-11-08 20:21

Rate this post
 0 ▲ useful ▼ not useful
Hello Scott,

> If I change the
> makefile so that optimizations are turned off (versus optimized for
> size), the resulting build (after doing a "make clean") will not run
> after flashing.  Also, I can't to stop at "main" as a breakpoint.

Do you compile with thumb-interwork?

I had here some problems with GCC 4.1.1 too. Here the results:

If you compile for ARM only, use the options: -mabi=aapcs

If you have set: -mthumb-interwork, you MUST set -mapcs-frame too.

I do not know why, perhaps it is magic, but this solve my problems.

Regards,

Michael

 Author: Scott K. (skirkpatrick) Posted on: 2006-11-08 20:58

Rate this post
 0 ▲ useful ▼ not useful
Michael Fischer wrote:
> Hello Scott,
>
>
> Do you compile with thumb-interwork?
>
> I had here some problems with GCC 4.1.1 too. Here the results:
>
> If you compile for ARM only, use the options: -mabi=aapcs
>
> If you have set: -mthumb-interwork, you MUST set -mapcs-frame too.
>
> I do not know why, perhaps it is magic, but this solve my problems.
>
> Regards,
>
> Michael

Yes, -mthumb-interwork is specified in the makefile.  That did fix one
problem in that now I can build a version with no optimization that
works, at least for flash.  I'm still having problems getting a RAM
version to the point that I can debug it.

 Author: Scott K. (skirkpatrick) Posted on: 2006-11-15 14:04

Rate this post
 0 ▲ useful ▼ not useful
Martin, do you have any thoughts?

 Author: Martin Thomas (Guest) Posted on: 2006-11-16 18:25

Rate this post
 0 ▲ useful ▼ not useful
Scott Kirkpatrick wrote:
> Martin, do you have any thoughts?

The code has been provided by Darrik Spaude. So far I have never tested
it here.

Could you set a breakpoint in the startup-code and see if the
interrupt-vectors are handled correctly (esp. for the FreeRTOS
"yield"-handler)?

Reason for the ctor-problem in "RAM_RUN" is obvious: there is something
missing in the RAM.ld (see ROM.ld). But there is no C++ in use so it's
save to remove the code which calls the static ctors from startup.S as

The remapping is not done automatically in RAM_RUN, you can set the
remap bit by writing the register from gdb via OpenOCD (take care: it's
a "every write toggles" bit).

Currently no idea about the optimization-problem.

Maybe I will have some time to do some tests next week.

 Author: Scott K. (skirkpatrick) Posted on: 2006-11-16 19:20

Rate this post
 0 ▲ useful ▼ not useful
Martin Thomas wrote:
> The code has been provided by Darrik Spaude. So far I have never tested
> it here.
>
> Could you set a breakpoint in the startup-code and see if the
> interrupt-vectors are handled correctly (esp. for the FreeRTOS
> "yield"-handler)?
>
> Reason for the ctor-problem in "RAM_RUN" is obvious: there is something
> missing in the RAM.ld (see ROM.ld). But there is no C++ in use so it's
> save to remove the code which calls the static ctors from startup.S as
>
> The remapping is not done automatically in RAM_RUN, you can set the
> remap bit by writing the register from gdb via OpenOCD (take care: it's
> a "every write toggles" bit).
>
> Currently no idea about the optimization-problem.
>
> Maybe I will have some time to do some tests next week.

Well, the ctor problem makes me feel stupid :)  I copied it from the
ROM.ld and changed it from FLASH to DATA and now it compiles fine.

I changed
THUMB_IW = -mthumb-interwork
to
THUMB_IW = -mthumb-interwork -mapcs-frame
as suggested by Michael Fischer and the optimization problem has gone
away.

In startup_SAM7S.S, the #if for the remap states:
#if defined(VECTORS_IN_RAM) || defined(RAM_RUN)

Right now, I've got it commented out as I do the remapping in my gdb
script but the silly thing still won't run in RAM.  Here's a copy of my
gdb script (obtained from Jim Lynch's tutorial):
target remote localhost:3333
monitor soft_reset_halt
monitor mww 0xFFFFFF00 0x01
monitor reg pc 0x00000000
monitor arm7_9 sw_bkpts enable
break main
continue

GDB never comes back from the continue command.

 Author: Lohit S. (lohits7) Posted on: 2009-03-14 10:24

Rate this post
 0 ▲ useful ▼ not useful

http://gandalf.arubi.uni-kl.de/avr_projects/arm_pr... the program works
well when using winarm tool chain , if the same project run on
codesourcery ,by changing arm-elf to arm-none-eabi i get the error as

serial/serialISR.c:106: internal compiler error: in
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://support.codesourcery.com/GNUToolchain/>; for instructions.
cs-make: *** [serial/serialISR.o] Error 1

regards

Lohit S

• $formula (LaTeX syntax)$