FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2016 Threads] Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by eduardobern on December 21, 2016 Hello,
I am trying to use the tickless low power feature of FreeRtos in my application.
I noticed that portSUPPRESSTICKSAND_SLEEP never get called, the only way to make it work is disabling the only task that i have in my test application. This is very weird because the test task that i have only does this:
for(;;)
{
if(xQueueReceive(handler->events, &curevent, portMAXDELAY) == pdTRUE)
{
FSMProcess((HSMPRIME*) handler, &cur_event);
}
}
I disabled all the interrupts that puts some data into this queue, so it would block indefinitely, leaving the system in IDLE state, i am using the IdleHook callback to make sure it is locked in this state, but still the portSUPPRESSTICKSAND_SLEEP doesnt get called. This is VERY frustrating.
configUSETICKLESSIDLE is 2
configEXPECTEDIDLETIMEBEFORESLEEP is 200
INCLUDE_vTaskSuspend is 1
I really cant figure out what is happening, Could you guys help me?
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by heinbali01 on December 22, 2016 I can not think of a reason, but could you try replace portMAX_DELAY with a value of e.g. 1000 ? Does that make a difference?
Could you through the code in tasks.c starting here:
~~~~
xExpectedIdleTime = prvGetExpectedIdleTime();
~~~~
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by eduardobern on December 22, 2016 Tried different values. Still not working. xExpectedIdleTime is always 0 when my test tasking is running which is why portSUPPRESSTICKSAND_SLEEP never get called. This two conditions are true in most times:
~~~
if( pxCurrentTCB->uxPriority > tskIDLE_PRIORITY )
{
xReturn = 0;
}
~~~
~~~
else if( uxHigherPriorityReadyTasks != pdFALSE )
{
/* There are tasks in the Ready state that have a priority above the
idle priority. This path can only be reached if
configUSE_PREEMPTION is 0. */
xReturn = 0;
}
~~~
I also modified my test task like this and still didnt work:
~~~
static void vTestTask(void * pvParameters)
{
TickTypet xLastWakeTime;
const TickTypet xFrequency = 450;
xLastWakeTime = xTaskGetTickCount();
for(;;)
{
vTaskDelayUntil( &xLastWakeTime, xFrequency );
}
}
~~~
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by eduardobern on December 22, 2016 Also noticed that this condition is always true when the test task is running
~~~
if( configUSEPORTOPTIMISEDTASKSELECTION == 0 )
{
if( uxTopReadyPriority > tskIDLE_PRIORITY )
{
uxHigherPriorityReadyTasks = pdTRUE;
}
}
~~~
It is acting like even with vTaskDelayUntil or xQueueReceive blocking my task, it always counts as a Ready state. Cant figure out why this is happening.
Update: Now there is something even more weird, i switched from FreeRtos v9 to FreeRtos v8.1 and it worked with the same application source code. I only got only one warning during the build related to cast in task.c.
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by rtel on December 22, 2016 This is on an MSP430F - did you provide your own implementation of the tickless idle feature? Which compiler are you using? If IAR then you should be able to use their StateViewer plug-in to see which task the system thinks is running.
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by eduardobern on December 26, 2016 Yes, i made my own implementation, but the problem was that the portSUPPRESSTICKSAND_SLEEP never get called. With some debugging i discovered that was because there was always at least one task in ready state which was not true since my only task was blocked due to vTaskDelayUntil.
Then I switched to FreeRtos 8.1 and the problem was gone.
I am using CCS 6.1 with Ti compiler.
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by rtel on December 27, 2016 Are you using software timers? If so, then the change history for V8.2 could have explained it perhaps, but I'm not sure about 8.1: http://www.freertos.org/History.txt
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by eduardobern on December 28, 2016 I am not using software timers. I just ported the freertos v9 to msp430fr4133 and made a simple tasks (that sleeps/blocks most of the time), but no matter what i do, all tasks always stays in ready status and then i couldnt make the tickless feature work.
I moved to freertos v8,1 and everything worked, but i get some warnings during the compilation.
I believe that is a problem with my enviroment and compiler, because there is a example code on freertos v9 with the msp430fr5 series that is very similar with my current msp430.
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by rtel on December 28, 2016 You can use the debugger to step through the prvGetExpectedIdleTime()
function in tasks.c to see why it is returning whatever it is returning.
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by eduardobern on December 29, 2016 It always returns 0 because of this condition inside the prvGetExpectedIdleTime() function:
~~~
else if( uxHigherPriorityReadyTasks != pdFALSE )
{
/* There are tasks in the Ready state that have a priority above the
idle priority. This path can only be reached if
configUSE_PREEMPTION is 0. */
xReturn = 0;
}
~~~
Problem with portSUPPRESS_TICKS_AND_SLEEP and msp430fr4Posted by rtel on December 30, 2016 That doesn't help. uxHigherPriorityReadyTasks is set in that function.
Why is it being set to pdTRUE?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|