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.

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

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

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. 

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…