EmbDev.net

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


Author: Scott Kirkpatrick (skirkpatrick)
Posted on:

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
a blinking LED.

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 Fischer (mifi)
Posted on:

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 Kirkpatrick (skirkpatrick)
Posted on:

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 Kirkpatrick (skirkpatrick)
Posted on:

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

Author: Martin Thomas (Guest)
Posted on:

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
already done.

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 Kirkpatrick (skirkpatrick)
Posted on:

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
> already done.
>
> 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
   load
   continue

GDB never comes back from the continue command.

Author: Lohit Shivanna (lohits7)
Posted on:

Rate this post
0 useful
not useful
please help me  .......


I have downloaded freertos project form 
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 
expand_expr_addr_expr_1, at expr.c:6833
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


please help me how to short out the problem for this


regards

Lohit S

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.