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_projects/at91sam7s256_FreeRTOS_Spaude_20060925.zip 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?
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
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.
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.
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.
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
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.