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

AT91SAM7X + GCC problems

Posted by Nobody/Anonymous on February 7, 2007
I'm having a very difficult time getting FreeRTOS running on the Atmel AT91SAM7X-EK evaluation board. I've got FreeRTOS 4.1.3, GNUARM 4.10, and newlib, and am unable to get either the lwIP_Demo_Rowley or even a simple light blinker to work.

After adding a syscalls.c (stubbed, except for _sbrk, which is implemented as per Red Hat's documentation), the lwIP demo compiles, but crashes with an undefined instruction in udp_recv.

A simple application (full code available on request) does better, but exhibits strange behavour: if I just let the code run, it dies with a data abort after a few ticks have elapsed. Depending on what debug stuff I've put in, it either dies towards the beginning of portRESTORE_CONTEXT, as called from vPreemptiveTick, or towards the end of vTaskSwitchContext, at the listGET_OWNER... line.

In both cases, it looks like the pxCurrentTCB variable is being set to something random (in the former crash, it's 0xa5a5a5a5, which is suspiciously like some guard value, and in the latter case it's in the high 0xb000s).

That's not the weird part, though. If I attach a JTAG debugger (SAM-ICE, with Segger's GDB server), and set a breakpoint in vPreemptiveTick, the code runs fine if I hit "continue" after the breakpoint. On the other hand, even with the debugger attached, and no breakpoint, I get the same crash.

I scattered various debugging traces throughout the code, looking for a corrupted pxCurrentTCB. What's weird is that in a few cases, including the trace statements made everything work!

Compiling with -fomit-frame-pointer made the code go longer (about 15 ticks), but it still crashes.

Any help would be appreciated.

RE: AT91SAM7X + GCC problems

Posted by Richard on February 7, 2007

> After adding a syscalls.c (stubbed, except for _sbrk, which is implemented as
> per Red Hat's documentation), the lwIP demo compiles, but crashes with an undefined
> instruction in udp_recv.

I don't know why you are adding syscalls.c and a different newlib. The demo should compile with the standard GNUARM installation, with no additions required.

As per the WEB docs - I have only tested this using a Windows host. Are you using a Linux distribution? Maybe there are some differences?

> A simple application (full code available on request) does better, but exhibits
> strange behavour: if I just let the code run, it dies with a data abort after
> a few ticks have elapsed. Depending on what debug stuff I've put in, it either
> dies towards the beginning of portRESTORE_CONTEXT, as called from vPreemptiveTick,
> or towards the end of vTaskSwitchContext, at the listGET_OWNER... line.


The simplest task would be something along the lines of:

void vTask( void * pvParaemters )
{
____for( ;; )
____{
________vTaskDelay( 500 );
________vParTestToggleLED( 0 );
____}
}

Then in main()

int main( void )
{
____prvSetupHardware();

____/* Setup the IO required for the LED's. */
____vParTestInitialise();

____xTaskCreate( vTask, "TASK", configMINIMAL_STACK_SIZE * 2, NULL, 1, NULL );

____vTaskStartScheduler();

____return 0;
}


Then **very importantly** set configUSE_IDLE_HOOK to 0 in FreeRTOSConfig.h. If you do not do this the program will crash as the idle hook will attempt to access the USB peripheral which is not setup in this simple case.

Is this the sort of demo you created? If not, can you try this code?


> In both cases, it looks like the pxCurrentTCB variable is being set to something
> random (in the former crash, it's 0xa5a5a5a5, which is suspiciously like some
> guard value, and in the latter case it's in the high 0xb000s)

0xa5a5a5a5 is the value that the stack is filled with when the task is created.

Make sure you are using the startup files and linker script that comes with the demo.

Regards.

RE: AT91SAM7X + GCC problems

Posted by Nobody/Anonymous on February 7, 2007
> I don't know why you are adding syscalls.c and a different newlib. The demo should compile
> with the standard GNUARM installation, with no additions required.

The GNUARM build of newlib supplies its own syscalls (read, write, etc), which assume the presence of an Angel_SWI monitor. Since neither FreeRTOS nor I provide one of these, the syscalls will fail to function. For what it's worth, my build of newlib was compiled with

../newlib-1.14.0/configure --target=arm-elf --prefix=/var/gnuarm \
--with-float=soft --disable-newlib-supplied-syscalls --enable-multilib

This is identical to the GNUARM build, except for the addition of the --disable-newlib-supplied-syscalls option. I eventually wish to provide my own versions of read, write, and so forth, so I can, say, provide a debugging channel over the serial port, or a flash-based file system, so this is important to me.

On a lark, I re-installed GNUARM, which also installed their build of the library. At that point, I was able to get both the shortened demo that you discuss, as well as my own (similar) project working. *However*, I can't use sprintf: if I make even a single call to sprintf, for some reason, the timer ticks stop appearing. This is true for my own demo, as well as for the stripped-down version (blinking LED only) of the lwIP demo.

I'm using Windows, for what it's worth.

I can provide all the source for both my demo and the stripped down lwIP demo, if it would make things easier.

Right now, I'm re-building newlib using the exact specifications provided on the GNUARM site, and I will test whether *this* build works.

Thanks for your help so far.



RE: AT91SAM7X + GCC problems

Posted by Nobody/Anonymous on February 8, 2007
Just my very humble opinion but it sounds like your stack is too small. Calling sprintf eats up lots of stack space so you may be overflowing the stack. You can try doubling or tripling your stack size and see if that clears things up. Then you can check how much stack is being used and adjust it accordingly.

RE: AT91SAM7X + GCC problems

Posted by hockeymonk on February 10, 2007
Also try reducing the FreeRTOS heap size in FreeRTOSConfig.h. I reduced configTOTAL_HEAP_SIZE from 22000 to 15000 and lwIP no longer crashes. I think this is related to lwIP memory usage being outside the control of FreeRTOS memory management. Depending on your user task you may need to prevent FreeRTOS from overrunning the lwIP TCB structures.

Just a thought...


[ 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