I am Currently Evaluating The FreeRTOS Kernel on an LPCXpresso LPC1114 EVB , Created two tasks ,
a non blocking one using the small printf lib to print out some string and the other is a periodic Task using the vTaskDelayUntil(&xTimeUpdate, (500/portTICK_RATE_MS)) API to have a sharp 500ms Delay , with a priority higher than the non-Blocking one , the Result is having the Periodic Task Executing Once and Leaving THE CPU for the non-Blocking Task forever ,this problem also occurs when using the vTaskDelay() API , I know that this problem may seem silly but im really stuck Please Help !!

The two most likely causes are
1) You have preemption turned off, thus the "non-blocking" task will never give up the processor unless you add a yield to the loop.

2) Your timer tick interrupt isn't working for some reason.

You can check the first by adding the yield.
The second by seeing if the tick counter is increasing.

- Preemtion is turned on , and working with Blocking Tasks Normally
- xTickCount does increment during Runtime , but increments slowly , it Should Reach 1000 Tick within 1 Second But That Does Not Happen

Any Advice?

“Any Advice?”

Start by ensuring the tick interrupt is executing at the expected frequency before adding in any additional functionality. You could leave your code as it is, and add in a tick hook function function that just toggles an IO port. Check the frequency at which the IO port toggles matches that expected according to your configTICK_RATE_HZ and configCPU_CLOCK_HZ settings in FreeRTOSConfig.h. Once you have the frequency correct you can then return to look at what your application is actually doing.

Regards.

- Downloaded NXPs FreeRTOS Example ,
- Experimented the xTickCount Found it incrementing by 1000 Persecond with a CLK Frequency 48000000
- Changed the Tick Frequency found Everything Going fine With Port 0 Pin 7 Led Toggling Frequency
- Switched Off Tick Hook Function , usedThe HeartBeating Task WITH NO BLOCKING And Made Another Led Toggling Task With A Higher Priority and a (configTICK_RATE_HZ / 2 ) Delay

Result is : xTickCount Increments 1 every Second , Higher Priority Task Runs Once and the HeartBeat Task Running Forever Not Giving UP CPU

using the NXP Example removed all tasks and left the HeartBeat Task and removed the vTaskDelay Blocking function to see the Task Behavior when being continuous , Found That the xTickCount Drops down its rate per second without touching the configuration file .

Is the peripheral used to generate the tick (or the configuration of the timer used to feed the peripheral that generates the tick) configured before the scheduler is started or by one of the tasks? If it is configured by one of the tasks then removing the task will stop the hardware being configured.

Can you remove the tasks one at a time to determine when the tick configuration changes.

The Peripheral Generating the Tick is a core peripheral (SysTick) common in Cortex-M Microcontrollers , and its configuration is standardized through CMSIS wich is used by FreeRTOS , the configuration API SysTick_Config( ) could be found in the xPortStartSchedular( ) API in the M0 Port , and its Arguments are configCPU_CLOCK_HZ and configTICK_RATE_HZ , not configured in one of the Tasks

*Arguments are (configCPU_CLOCK_HZ / configTICK_RATE_HZ)

If all the hardware setup is done before the scheduler is started then I'm afraid I have no explanation why the hardware setup would differ after the scheduler has started just because you didn't create the same tasks.

Are you using the NXP version of the M0 port or the FreeRTOS version (the one in the FreeRTOS download)?

Regards.

Im Using NXP's Version

I have Lately realized that the version of NXP Port and Example i am using is buggy , Will be trying an updated one , Thank you very Much Richard Barry for your support and Excellent RTOS Thank you Richard Damon and DaveDors