Massive problems with Crossworks

nobody wrote on Wednesday, August 16, 2006:

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.

Anybody shed any light on this problem.

nobody wrote on Wednesday, August 16, 2006:

I have no problem but there have been some posts with people not being able to upload their code.  Could this be your problem?

Are you using build 3 of cross studio?

Do you have to include different header files to change code from a sam7x to sam7s?

nobody wrote on Wednesday, August 16, 2006:

I’m using 1.6 build 3 of Crossworks.

Yes, changed header files.

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.

My project in debug mode is about 120K.

nobody wrote on Wednesday, August 16, 2006:

The SAM7S256 and SAM7X256 have the same internal flash memory map so it makes no sense.

lwIP uses a lot of RAM so more likely RAM is the problem.

When you run just one task assigning a large stack to that task to discount this as the problem cause.

Sorry to ask obvious question.  You have done a complete rebuild?

nobody wrote on Wednesday, August 16, 2006:

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!

rtel wrote on Wednesday, August 16, 2006:

+ 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

Let me know.


nobody wrote on Wednesday, August 16, 2006:

To let people know what is going on here…

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.

rtel wrote on Wednesday, August 16, 2006:

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 will pass on more as/when I can.


nobody wrote on Wednesday, August 16, 2006:

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.

Thanks for your update. :slight_smile:

rtel wrote on Wednesday, August 16, 2006:

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.


nobody wrote on Wednesday, August 16, 2006:

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!


nobody wrote on Wednesday, August 16, 2006:

Are you using a CrossConnect?  If so these are my settings that are working very well.

Adaptive clocking = no.
Identify target = yes.
JTAG clock divider = 1.
Erase all = no.
Debug interface type = ARMTDI
Memory access time = 1000
Processor stop timeout = 500

Version is 2.1 built 29 March 2006.

Is anything different?  I am using an X not an S variant of the SAM7.

nobody wrote on Thursday, August 24, 2006:

Hi Guys!!!
Please publish full project SAM7 for CrossWorks…

nobody wrote on Thursday, August 24, 2006:

? there is a full project for sam7, i’m using it.

nobody wrote on Thursday, August 24, 2006:

Sorry. For SAM7S64. I have found only for SAM7X, project "lwIP_Demo_Rowley_ARM7".

nobody wrote on Monday, August 28, 2006:

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. */

        extern void debug_int_call();
        //------------------------- 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;
                AT91C_BASE_PIOA->PIO_SODR = LD;   

                /* Increment the tick count - this may wake a task. */

                /* Find the highest priority task that is ready to run. */
                /* End the interrupt in the AIC. */
        }// else debug_int_call();

best rgs