Problem changing Tick time from 1ms to 10ms

Kernel
1

ozsmit wrote on Wednesday, November 21, 2012:

My default project(ARM7_LPC2138) seem to be set up for a 1ms tick timer.  I defined my hardware timer to be 1ms and everything works fine.

I wanted to now change my hardware timer to 10ms as this is the value of my original platform and I changed the following:

in FreeRTOSConfig.h :
(Changed from 1000 to 100)
#define configTICK_RATE_HZ ( ( portTickType ) 100 )
in portmacro.h:
(Left Alone)
#define portTICK_RATE_MS ( ( portTickType ) 1000 / configTICK_RATE_HZ )
In main.c:
(Left Alone)
#define mainLED_DELAY ( ( portTickType ) 500 / portTICK_RATE_MS ) //500 for 1ms tick
#define mainERROR_LED_DELAY ( ( portTickType ) 50 / portTICK_RATE_MS ) //50 for 1ms tick
#define mainCHECK_DELAY ( ( portTickType ) 5000 / portTICK_RATE_MS ) // 5000 for 1ms tick

I changed the timer value on my system so that I would get 10ms interrupts.

What I am seeing is the first few LED_Delay are correct at 500ms each, but then the Check Task Fails and Led Flash every 50ms.

Why would my checkTask fail? (FAIL is printed on the debug Terminal screen)

With the timer set to 1ms tick in hardware, I pass 100% of the time.

Did I forget to change something else to go to a 10ms tick?

Thanks,
Ozmit

2

rtel wrote on Wednesday, November 21, 2012:

It depends which of the standard demo tasks are being executed.  Some include code that checks things happen within the time bounds they expect, and having courser time measurements can make these checks fail.  In effect these are false positives.

Your changes look ok.  Just changing configTICK_RATE_HZ should be enough by itself as the constant is used to configure the timer for the correct tick period.

If the LEDs are flashing at the correct rate when the check task is not running then I don’t think you have any issue.

Regards.

3

ozsmit wrote on Wednesday, November 21, 2012:

I agree, It seems to work fine. 

How would I fix the checkTask  Fail problem?  It seems like a nice feature to have.

My project has the following tasks:
/* Create the queue used to pass message to vPrintTask. */
xPrintQueue = xQueueCreate( mainQUEUE_SIZE, sizeof( char * ) );

/* Create the semaphore used to wake vButtonHandlerTask(). */
vSemaphoreCreateBinary( xButtonSemaphore );
xSemaphoreTake( xButtonSemaphore, 0 );

/* Start the standard demo tasks. */
vStartIntegerMathTasks( tskIDLE_PRIORITY );
vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY );
vStartSemaphoreTasks( mainSEM_TEST_PRIORITY );
vStartDynamicPriorityTasks();
vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );

#if configUSE_PREEMPTION == 1
{
/* The timing of console output when not using the preemptive
scheduler causes the block time tests to detect a timing problem. */
vCreateBlockTimeTasks();
}
#endif

        vStartRecursiveMutexTasks();

/* Start the tasks defined within this file. */
xTaskCreate( vLEDTask, ( signed char * ) “LED”, configMINIMAL_STACK_SIZE, NULL, mainLED_TASK_PRIORITY, NULL );
        xTaskCreate( vCheckTask, ( signed char * ) “Check”, configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );
        xTaskCreate( vPrintTask, ( signed char * ) “Print”, configMINIMAL_STACK_SIZE, NULL, mainPRINT_TASK_PRIORITY, NULL );
        xTaskCreate( vButtonHandlerTask, ( signed char * ) “Button”, configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );

/* Start the scheduler. */
vTaskStartScheduler();

And I am using the follwoing checkTask():

static void vCheckTask( void *pvParameters )
{
portBASE_TYPE xErrorOccurred = pdFALSE;
portTickType xLastExecutionTime;
const char * const pcPassMessage = “PASS\n”;
const char * const pcFailMessage = “FAIL\n”;

/* Just to remove compiler warnings. */
( void ) pvParameters;

/* Initialise xLastExecutionTime so the first call to vTaskDelayUntil()
works correctly. */
xLastExecutionTime = xTaskGetTickCount();

for( ;; )
{
/* Perform this check every mainCHECK_DELAY milliseconds. */
vTaskDelayUntil( &xLastExecutionTime, mainCHECK_DELAY );

/* Has an error been found in any task? */

if( xAreIntegerMathsTaskStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xArePollingQueuesStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xAreSemaphoreTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xAreDynamicPriorityTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

if( xAreBlockingQueuesStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

#if configUSE_PREEMPTION == 1
{
/* The timing of console output when not using the preemptive
scheduler causes the block time tests to detect a timing problem. */
if( xAreBlockTimeTestTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}
}
#endif

if( xAreRecursiveMutexTasksStillRunning() != pdTRUE )
{
xErrorOccurred = pdTRUE;
}

/* Send either a pass or fail message.  If an error is found it is
never cleared again. */
if( xErrorOccurred == pdTRUE )
{
xLED_Delay = mainERROR_LED_DELAY;
xQueueSend( xPrintQueue, &pcFailMessage, portMAX_DELAY );
}
else
{
xQueueSend( xPrintQueue, &pcPassMessage, portMAX_DELAY );
}
}
}

I should probably set a break point to see which one fails, however I am away from my developement platform at the moment.

Ozmit

4

rtel wrote on Wednesday, November 21, 2012:

The demo tasks are not required, they are literally just that, there for demonstration so don’t worry about taking them out. 

Having said that, some actually do some useful tests too, and it is those that are likely to be causing you a problem with a different tick value.

The prime suspect will be the tasks created by the vCreateBlockTimeTasks() function call.  These test that tasks remain in the Blocked state for the expected number of time.  The tests will allow a little margin to account for the fact that interrupts will execute, and other tasks may share their priority.  If you have changed the tick frequency it is likely that the measurable time granularity will take the measured block time outside of the allowed margin.

Maybe the vStartDynamicPriorityTasks() tasks could suffer a similar problem, but I can’t remember without looking at their implementation again.

Regards.