Hi Richard, I’ve ported a very basic project (single task, blink an LED at 1 Hz) over to GCC compiled using WinARM (http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ ). After no success, I’ve traced the problem to the interrupted task never being returned to.  The single task starts and runs normally.  Then the first PIT interrupt occurs and vPreemptiveTick appears to execute successfully, but the task never gets control again.  The task just hangs on the vTaskDelay(), but I’ve verified that vPreemptiveTick executes at least once.  Have you seen such an issue with the GCC port for the AT91SAM7S? I’ve sent my entire project in case you can take a look. Much appreciated.

Hi, As the WEB documentation says, it is always best to start a new project based on an existing project.  That way you have all the correct setup (startup files, command line options, etc.).  Take a look at the ARM7_AT91FR40008_GCC demo.  This has all the setup you require, just for the wrong (but similar) chip! In particular take a look at the startup files.  These are much simpler than the Atmel files you are using. This thread provides more information: https://sourceforge.net/forum/forum.php?thread_id=1334178&forum_id=382005 The startup files have to setup stacks for the relevant modes, then ensure main is called from the Supervisor mode.  Not much else.  The interrupt handling saving and restoring of the context is then handled by the macros we have previously discussed.  At the moment when you get an interrupt the Atmel code is running, then the FreeRTOS code, so things are getting muddled up. I have send you the startup files that I am using with my Rowley CrossWorks GCC port on the SAM7.  Hopefully you will be able to use these directly, but remember I am using a slightly different chip so there could be some differences in the C file (perhaps). Let us know how you get on. Regards.

Thanks for the reply and the files.  Unfortunately there are a number of undefined references in the crt0.S file: crt0.o:crt0.S:249: undefined reference to `__stack_und_end__’ crt0.o:crt0.S:249: undefined reference to `__stack_abt_end__’ crt0.o:crt0.S:249: undefined reference to `__stack_irq_end__’ crt0.o:crt0.S:249: undefined reference to `__stack_fiq_end__’ crt0.o:crt0.S:249: undefined reference to `__stack_svc_end__’ crt0.o:crt0.S:249: undefined reference to `__stack_end__’ crt0.o:crt0.S:249: undefined reference to `__data_load_start__’ crt0.o:crt0.S:249: undefined reference to `__data_start__’ crt0.o:crt0.S:249: undefined reference to `__data_end__’ crt0.o:crt0.S:249: undefined reference to `__text_load_start__’ crt0.o:crt0.S:249: undefined reference to `__text_start__’ crt0.o:crt0.S:249: undefined reference to `__text_end__’ crt0.o:crt0.S:249: undefined reference to `__fast_load_start__’ crt0.o:crt0.S:249: undefined reference to `__fast_start__’ crt0.o:crt0.S:249: undefined reference to `__fast_end__’ crt0.o:crt0.S:249: undefined reference to `__heap_start__’ crt0.o:crt0.S:249: undefined reference to `__heap_end__’ crt0.o:crt0.S:249: undefined reference to `__ctors_start__’ crt0.o:crt0.S:249: undefined reference to `__ctors_end__’ crt0.o:crt0.S:249: undefined reference to `__dtors_start__’ crt0.o:crt0.S:249: undefined reference to `__dtors_end__’ Are these all defined in the Rowley files, or is there perhaps a missing .h file you could pass my way?  :) Also, would it be simpler to modify the existing Atmel-made Cstartup.S file, or are there a lot of changes to be made? Regarding the "possible virus", that’s just our silly server freaking out because I’m sending a zip file. Thanks much for all the help (hopefully the results will be quite useful to those using FreeRTOS with WinARM and the AT91SAM7S64).

This is probably stuff your linker script is looking for.  Try taking the linker script from the DemoARM7_AT91FR40008_GCC directory, then edit the flash and ram start address and size to be correct for your chip (lines 3 and 4 in the AT91FR40008 linker script). This script is much simpler, which is always a good thing :-)

No luck, unfortunately.  Only a small fraction of those sections are defined in the AT91FR40008 linker script.  With the modified AT91FR40008 script and using that project’s boot.S I can get it to compile but it doesn’t run properly (different startup code issues I’m assuming). Is there a linker script generated by your Rowley project somewhere hidden that contains all these definitions??  :) If you had any comments on how to modify the Cstartup.S from Atmel to work with FreeRTOS I could try pursuing that as well.

Could you send me your entire project again please?  I will try and build it.

Have a look at the attached. I have replaced the startup and linker scripts, renaming the originals with _. The linker script is very simple – check that I have the rom and ram size and location correct for your device.  It depends on how the remap command is used by your jtag. The startup code does nothing device specific (ie Atmel specific), only ARM specific, so should be usable on all arm chips (?).  The peripherals are NOT setup.  AT91F_LowLevelInit() is not called from the startup code but can easily be called as the first thing done in main(). It builds and links, but I have not tried it.  What hardware are you using? I only have the IAR demo boards with SAM7 chips.  Also I am using a different build of GCC. Make sure you have the environment variables set correctly, as per my previous email, before building. Odd things: +It builds VERY slowly, don’t know why.  My other GCC projects are much faster.  Must be makefile related? +There are a lot of multiple inclusion compiler warnings generated that I have not seen before.  Maybe the makefile has a particular warning option turned on? Regards.

It works!  With one minor flaw in the startup… In the linker script I believe the 7th line should also be changed from "__stack_end__ = 0x00300000 + 256K – 4;" to "__stack_end__ = 0x00200000 + 16K – 4;". It looks like you made the same modifications I did to the AT91FR4008 project (per your suggestions of course) and that I had given up too early. Calling AT91F_LowLevelInit() first in main sets up the clock eventually and the program indeed appears to function properly and the LED blinks at 1 Hz!! The downside however is that it takes over *3 seconds* to start up and begin blinking, I’m assuming because the processor is operating off of the incredibly slow internal clock for a much longer period since AT91F_LowLevelInit() is called in main rather than from assembly earlier on. I assume the solution is either to call AT91F_LowLevelInit() earlier in the assembly or just add some assembly to handle the PLL configuration earlier on.  Is it safe to do this most anywhere?

You can configure the PLL as one of the first things in the code, I will send an example.