Anybody else having problems with FreeRTOS and crossworks on a SAM7S256?
If I take the rowley lwIP demo and build it (with only the flash task included), FreeRTOS doesn’t start up - it crashes. If I remove lwIP & basicWEB.c from the source tree and re-build (even though they’re not being called) it runs.
My own project I have ethernet & USB now working (the USB CDC example), but now I’m seeing the same sort of problem.
With the Idle task for USB as was in the lwIP demo, it all works fine. If I comment out the code inside the idle task, it crashes, doesn’t even appear to start up any tasks.
It only works when the provided idle code is in place. I even tried swapping it out for my own which just echos back on the CDC com port, but that causes a crash as soon as the scheduler starts, none of the tasks seem to start (i put breakpoints in them).
Getting very frustrated there, it would appear as if crossworks is not compatible with FreeRTOS.
It just ends up in data abort at the moment. :( I’m just not asking it to do anything, the only running task is one that flashes a led.
If I were to remove lwIP from the project I’m 100% convinced it’d work properly, it seems like as soon as the object code goes over a certain size it all stops working.
You’ve misunderstood what I’ve done, I probably wasn’t very clear. I completely removed all calls to lwIP, it’s only resident in the flash, never called.
With my first test I used the lwIP demo from the distribution, and removing all unwanted calls. Having lwIP in the memory map resulted in freertos crashing, despite the fact that there were no calls to it, main consisted of only 3 lines, one to start the flash task, one to start the scheduler and a return (0)!
With lwIP present in the build, freertos crashes on the scheduler call. With FreeRTOS removed from the project, it runs as expected.
Yes, done many builds, cleaning is my favourite pasttime!
+ Open up the project: FreeRTOS/Demo/CORTEX_LM3S102_Rowley/RTOSDemo/hzp.
+ Take a look at the file included in the project called vectors.s.
+ Search for the text "STARTUP_FROM_RESET".
You will see that STARTUP_FROM_RESET redefines the reset vector depending on
whether or not STARTUP_FROM_RESET is defiend in the project. If running in
the debugger STARTUP_FROM_RESET is defined using the preprocessor, if
running stand alone then STARTUP_FROM_RESET is not defined.
When STARTUP_FROM_RESET is defined then on reset you jump straight to _start
which is defined within thumb_crt0.s, also in the same project.
Could you try doing the same in your project. I suspect it will fix your
problem.
Sometimes after downloading code to the processor, it’ll just crash, which is the random crashing I am seeing.
If I power off the target and turn it back on again and download the *same* build of the same code, it’ll run quite happily.
I make some changes to the code and it all runs fine. Later, I make more changes and download and it crashes. Power off, re-download and it runs. Repeat…
Richards suggestion of the reset vector jumping to itself sounded promising, but didn’t solve the problem.
I think now maybe I should be hunting out the errata sheet (although it seems to have gone missing from atmels site) on the processor to see if it’s coming up in a non-default state over jtag and if that is causing the problems.
Once it gets into this state, no amount of re-downloading will sort it out until the power is removed, then it all works happily.
I have spoken with Rowley tech support on this. They suggest it is not a good idea to mix pre and post CrossWorks V1.6 files. The FreeRTOS download was created using V1.5, then converted to use V1.6 without recreating the whole project. Maybe this is a cause of the problem. Also, this is related to my previous suggestion regarding the STARTUP_FROM_RESET definition.
Another thing mentioned was that the SAM7 support files must be downloaded separately and installed for CrossWorks V1.6, and simply copying the support files from an old V1.5 installation into the V1.6 directory structure can cause problems.
I would think this would also be problem, my project was created in 1.6 from scratch, not using one of the demonstation projects from the distribution, I figured that I needed to understand how it all bolted together as this is my first attempt at using FreeRTOS.
Because I modified the startup files (vectors.s, etc.) I included these locally within the project directory structure rather than referencing them from the CrossWorks installation directory. Therefore, even if you created the whole project from new, if you used the assembly files from the FreeRTOS download there will still be a mix of V1.5 and V1.6 files.
It might be worth checking the differences between the startup files included in the project (if you used these in your project) and those in the Rowley installation directory to see if there is anything different that could cause a problem - although this is unlikely.
No, I used the startup files from 1.6. The only files that came across from the distribution were the FreeRTOS c files, not any other supplimentary files.
I figured doing that would give me the best chance of getting up and running without any problems!
I guess you have problems with SWI handler - I had that for example. OS was crashing during taskYield. But you have not vTaskDelay there so it is something other. Do you checked PIT interrupt of OS? I have added in my portISR.c led control:
static volatile char ctl_led_div;
/* The preemptive scheduler is defined as "naked" as the full context is
saved on entry as part of the context switch. */
void vPreemptiveTick( void ) __attribute__((naked));
void vPreemptiveTick( void )
{
/* Save the context of the current task. */
portSAVE_CONTEXT();
extern void debug_int_call();
if (AT91C_BASE_PITC->PITC_PISR & AT91C_PITC_PITS) {
//------------------------- blinking LED - system is alive ---------- #define LD 2 // should be 500Hz at output…
if ((ctl_led_div++ % 100)==0)
if (AT91C_BASE_PIOA->PIO_ODSR & LD)
AT91C_BASE_PIOA->PIO_CODR = LD;
else
AT91C_BASE_PIOA->PIO_SODR = LD;
