problem running FreeRTOS

jordonhofer wrote on Thursday, August 09, 2007:

Hi.  I have been working with FreeRTOS on an LPC2366 (ARM7TDMI-S) on a custom-made board.  I am using CrossStudio with a JLink debugger.  So far it has been a very positive experience.

Starting with the original demo, I started tweaking to make it do what I want it to do.  I made a task to manage the flash pattern of 4 LEDs.

When I started adding some functions that we use on our other boards, at some point it quit running.  After playing with it to see what happened, I have it tracked down to a single line of code that doesn’t even get called yet (“size += 4;” if you’re interested :).  I don’t think this line is the cause, but adding it causes the program not to run (no LED activity) and commenting it out makes the program run (LEDs flash like they should.)  It looks to me like a memory boundary issue or something.

The strange thing is that I have 220.5 kB of the 256kB of FLASH free and 6.1 kB of the 32kB of SRAM free.  It doesn’t look like I am running out of memory.

Does anyone have any ideas on what could cause this or what to do to learn more about this problem?



rtel wrote on Thursday, August 09, 2007:

Sorry for brief reply:

Have you checked the size of the heap allocated to  You may have RAM free, but it might not be available to  Check out the memory management section of the WEB site.

Also, double check the stack that your task has.  Maybe it is running out.  The demos tend to be written to use absolutely the minimal stack that they can, and also generate tasks until the RAM is exhausted.


jordonhofer wrote on Friday, August 10, 2007:

Thank you for the quick reply!

The “configTOTAL_HEAP_SIZE” was set to 18K.  I bumped it up to 24K and that didn’t make a difference.

I have added 2 tasks to the demo - one to handle the LED flashing and one to do the processing that this board was made to do.  I have the main processing task and the uIP task commented out so only the LED task and the "standard demo tasks" (some of which can probable be removed).  I made the stack size of the LED task bigger and that also had no effect.

I am new to this environment, so what is a good way to see what is happening when it doesn’t run?


davedoors wrote on Friday, August 10, 2007:

Anything here: of any help?

jordonhofer wrote on Friday, August 10, 2007:

Nothing in that document helped.

Here is the main function:


  // Create the lwIP task.  This uses the lwIP RTOS abstraction layer.
  xTaskCreate( vuIP_Task, ( signed portCHAR * ) "uIP", mainBASIC_WEB_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY - 1, NULL );

  // Create the worker task.
  xTaskCreate( vWorker_Task, ( signed portCHAR * ) "worker", 128, NULL, mainCHECK_TASK_PRIORITY - 1, NULL );

  // Create the LED task.
  xTaskCreate( vLED_Task, ( signed portCHAR * ) "LEDs", 64, NULL, mainCHECK_TASK_PRIORITY - 1, NULL );

  // The suicide tasks must be created last as they need to know how many
  // tasks were running prior to their creation in order to ascertain whether
  // or not the correct/expected number of tasks are running at any given time.
  vCreateSuicidalTasks( mainCREATOR_TASK_PRIORITY );


  // Start the scheduler.


  // Will only get here if there was insufficient memory to create the idle task.
  return 0;


I always see "Starting…" when the program starts and I have never seen "STOPPING!!!" yet.  If I pull out some of the code I added so it runs, the LED task flashes the lights like it should and I can ping the board.  If I put the code back in, the LEDs are all dim (from floating pins i guess) and I cannot ping the board.  When I pause the program, the disassembly window that pops up is full of "       00000000   andeq r0, r0, r0" lines.


sashiono wrote on Tuesday, August 14, 2007:

the LPC2366 has some hardware issues, you need to read the eratta.
Mainly disable the MAM and run it at 60Mhz or slower.