Switch interval TaskDelay / TaskDelayUntil

Hi guys, I’m facing a problem with vTaskDelay or vTaskDelay until using 2 tasks just to blink LED’s.
The problem is when I use 1000 ticks, the led blinks every 1050 ms, and if I change to 500, every 550ms , the same occurs at 100 > 150 , so the 50ms it’s constant.
The Timer0 is config to interrupt every 1 ms, and the configs from RTOS I suppose it’s ok as above : #define configCPU_CLOCK_HZ ( ( unsigned long ) 48000000 ) /* =12.0MHz xtal multiplied by 5 using the PLL. */
#define configTICK_RATE_HZ ( ( portTickType ) 1000 ) #define portTICK_RATE_MS ( ( portTickType ) 1000 / configTICK_RATE_HZ ) The mainly problems are : I can’t use anything lower then 50ms for switching, the task 1 and task 2 , supposed to blink together, has 50ms between then, and the interval of blinking has 50ms more… I supposed it’s not ok, because we use a tick of 1 ms, it’s 50x less, and there are only 2 tasks (doing nothing ) Somebody know the reason for this “delay”? This is the source of the task’s static void vTeste2( void *pvParameters )
{
portTickType xLastWakeTime;
xLastWakeTime = xTaskGetTickCount ();
while (1) {
vTaskDelayUntil( &xLastWakeTime, 500 );
//vTaskDelay( 5 );
FIO1PIN ^= (1 << 18);
}
} static void vTeste3( void *pvParameters )
{
portTickType xLastWakeTime;
xLastWakeTime = xTaskGetTickCount ();
while (1) {
vTaskDelayUntil( &xLastWakeTime, 500 );
FIO1PIN ^= (1 << 24);
}
} Best regards,
Vinicius

Switch interval TaskDelay / TaskDelayUntil

Knowing which cpu you are using would help. Looks probably to be an NXP something or other. I expect the issue will be external to the code you have posted though. Maybe in the timer set up, the clock set up, where the timer is cleared, something else the cpu is doing (high interrupt load from elsewhere?, etc). Do the standard flash tasks in the demo application flash with a correct frequency? Did you base your application on the demo?

Switch interval TaskDelay / TaskDelayUntil

I’m using a NXP LPC 2387. I can share the Timer config, but it’s important it’s a fixed delay even in 1s, or 0.5s so it’s a fixed between SWITCH and not related to delay it self. Best regards,
Vinicius

Switch interval TaskDelay / TaskDelayUntil

Additional info : Timer setup static void prvSetupTimerInterrupt( void )
{
unsigned long ulCompareMatch; /* A 1ms tick does not require the use of the timer prescale.  This is
defaulted to zero but can be used if necessary. */ PCLKSEL0 = (PCLKSEL0 & (~(0x3<<2))) | (0x01 << 2); T0TCR  = 2;         /* Stop and reset the timer */
T0CTCR = 0;         /* Timer mode               */ T0PR = portPRESCALE_VALUE; /* Calculate the match value required for our wanted tick rate. */
ulCompareMatch = configCPU_CLOCK_HZ / (configTICK_RATE_HZ);
ulCompareMatch-; T0MR0 = ulCompareMatch; /* Generate tick with timer 0 compare match. */
T0MCR = 3; /* Setup the VIC for the timer. */
//VICINTSELECT &= ~( portTIMER_VIC_CHANNEL_BIT );
VICINTENABLE = 0x00000010; /* The ISR installed depends on whether the preemptive or cooperative
scheduler is being used. */
#if configUSE_PREEMPTION == 1
{
extern void ( vPortPreemptiveTickEntry )( void ); VICVECTADDR4 = ( unsigned long ) vPortPreemptiveTickEntry;
}
#else
{
extern void ( vNonPreemptiveTick )( void ); VICVECTADDR4 = ( long ) vPortNonPreemptiveTick;
}
#endif VICVECTPRIORITY4 = 1;//portTIMER_VIC_CHANNEL | portTIMER_VIC_ENABLE; /* Start the timer – interrupts are disabled when this function is called
so it is okay to do this here. */
T0TCR = portENABLE_TIMER;
} IRQ handler __arm void vPortPreemptiveTick( void );
__arm void vPortPreemptiveTick( void )
{
/* Increment the tick counter. */
vTaskIncrementTick(); /* The new tick value might unblock a task.  Ensure the highest task that
is ready to execute is the task that will execute when the tick ISR
exits. */
vTaskSwitchContext(); /* Ready for the next interrupt. */
T0IR = 1;
VICADDRESS = 0;
} Even with the issue of “intervals” I  had continue my work, and another issue that I’m facing it’s a port of a TCP/IP stack, that I’m receving a OVERRUN at 115K baudrate, i’m using a 16bytes FIFO buffer, and this “port” already works without RTOS.
I had changed the “uart” driver to be compatible, and i’m using only 1 task to test. Can somebody give me tips how to analyse the switch context 50ms (plus)  interval and the overrun? I’m using IAR and probably it’s some interruption or another thing like this, but I have no “clue” how to evaluate what is giving this bad result at all. My best regards,
Vinicius