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.
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!
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).
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 Demo\ARM7_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.
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?
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?
