FreeRTOS FAQ - My application does not run, what could be wrong?

I don't know - its your application - but here are some common solutions:

Stacks [see also the uxTaskGetStackHighWaterMark() API function, and the stack overflow detection options] Stack overflow is by far the most common source of support requests. The size of the stack available to a task is set using the usStackDepth parameter of the xTaskCreate() API function. Try increasing the size of the stack allocated to the task that is causing the problem, or reducing the amount of stack that the task utilises. Don't write interrupt service routines that require a lot of stack. Tasks that make calls to any string formatting functions are likely to require a lot of stack - particularly when using the GCC compiler. Such tasks are particularly prone to stack overflow. Each byte of the task stack is set to 0xa5 when the task is created, making it relatively simple to see if a stack overflow has occurred. In addition - the function usTaskCheckFreeStackSpace() in task.c demonstrates how the stack usage can be checked at run time (although this is a somewhat inefficient function so should only be used for debugging). I added a simple task to a demo, and now the demo crashes! Creating a task requires memory to be obtained from the kernel heap. Many of the demo application projects dimension the heap to be just big enough to run the demo tasks - so not big enough for any further tasks to be added to the project. The idle task is automatically created when you start the scheduler. If there is insufficient heap available for the idle task to be created then vTaskStartScheduler() will return - causing the application to never even start. To rectify this, increase the heap space, or remove some of the demo application tasks. Using API functions within interrupts Do not use API functions within interrupt service routines unless the name of the API function ends with "...FromISR()". The scheduler crashes when attempting to start the first task If you are using an ARM7 target then the processor must be in Supervisor mode when the scheduler is started. The interrupt enable flag gets set incorrectly Do not use any method for disabling and enabling interrupts other than calls to portENTER_CRITICAL() and portEXIT_CRITICAL(). These macros keep a count of the call nesting depth to ensure interrupts only become enabled again when the call nesting has unwound completely to zero. My application crashes before the scheduler is even started A context switch cannot occur until after the scheduler has started. Any interrupt service routine that could potentially cause a context switch must therefore not be permitted to execute prior to the scheduler being started. The same is true of any interrupt service routine that attempts to send to or receive from a queue or semaphore. Many API functions cannot be called prior to the scheduler being started. It is best to restrict such usage to the creation of the tasks, queues and semaphores that will be used once the scheduler activity has commenced. Suspending the scheduler (calling vTaskSuspendAll()) causes me problems Do not call API functions while the scheduler is suspended. Some functions can be used, but not all. This is not the intended purpose of the suspension mechanism. I have created a new application - but it will not compile Base new applications on the provided demo project file for the port you are using. This way you will be sure that the correct files are included and the compiler is correctly configured.

What else can I do?

1. Check the list of known issues on the download page.
2. Post a description of your problem in the support forum.