Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Massive problems with Crossworks

Posted by Nobody/Anonymous on 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.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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?

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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?

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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!

RE: Massive problems with Crossworks

Posted by Richard on 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
problem.

Let me know.

Regards.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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.

RE: Massive problems with Crossworks

Posted by Richard on 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.

Regards.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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. :)



RE: Massive problems with Crossworks

Posted by Richard on 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.

Regards.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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!

Thanks.


RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on August 24, 2006
Hi Guys!!!
Please publish full project SAM7 for CrossWorks...

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on August 24, 2006
? there is a full project for sam7, i'm using it.

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on August 24, 2006
Sorry. For SAM7S64. I have found only for SAM7X, project "lwIP_Demo_Rowley_ARM7".

RE: Massive problems with Crossworks

Posted by Nobody/Anonymous on 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. */
portSAVE_CONTEXT();

extern void debug_int_call();
if (AT91C_BASE_PITC->PITC_PISR & AT91C_PITC_PITS) {
//------------------------- blinking LED - system is alive ----------
#define LD2// 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;

//-------------------------------------------------------------------

/* Increment the tick count - this may wake a task. */
vTaskIncrementTick();

/* Find the highest priority task that is ready to run. */
vTaskSwitchContext();

/* End the interrupt in the AIC. */
AT91C_BASE_AIC->AIC_EOICR = AT91C_BASE_PITC->PITC_PIVR;
}// else debug_int_call();

portRESTORE_CONTEXT();
}

best rgs
Janusz


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists