Tickless cortex-m3

anonymous wrote on Sunday, July 14, 2013:

Hi,

Im using the tickless option on a lpc1769 but im having an issue. I got into deepsleep and exit when an RTC nterrupt happens. I can see that the vPostSleepProcessing is executed but the rtos goes back to sleep as vPreSleepProcessing is called again. I have put leds to see where the code is.
The task that called vTaskDelay never gets executed.
What would goes this behaviour? Should it resume to the task?

Nick

rtel wrote on Sunday, July 14, 2013:

It’s difficult to say, as I presume this is your own implementation.  Did you copy the example implementations provided for the SAM4L and RX100?  You should be able to use exactly the same structure, just change the clock source and ensure the correct interrupt is being handled.

I’m not sure what you mean by the RTOS goes back to sleep as vPreSleepProcessing is called again.  I presume you mean the RTOS puts the CPU back to sleep - and if vPreSleepProcessing as been called then immediately after that the RTOS will put the CPU to sleep - as intended.  Do you mean vPreSleepProcessing is being called unexpectedly?  Or more than once?

Regards.

anonymous wrote on Sunday, July 14, 2013:

Hi,

Yes  vPreSleepProcessing is being called unexpectedly, Or more than once.
Can I use configUSE_IDLE_HOOK 1 and configUSE_TICK_HOOK 1?

Nick

rtel wrote on Sunday, July 14, 2013:

You can see the conditions under which the function is called by looking at the definition of prvIdleTask() in tasks.c.  If you search for “portTickType xExpectedIdleTime” you will find it.

If the expected idle time is greater than configEXPECTED_IDLE_TIME_BEFORE_SLEEP then you will enter the port specific function that puts the CPU to sleep.  The expected idle time is set by the function prvGetExpectedIdleTime() in the same file.  You will see that it will return 0 if there are any other ready state tasks.

Try stepping through those functions to see why you think it is being called unexpectedly.

Regards.

anonymous wrote on Thursday, August 01, 2013:

Hi,

I finally had sometime to look into this part as I need to implement. I cant use the debugger but I think I know what might be the issue.
Does vPreSleepProcessing get called when vTaskDelay is called or as well when tasks are in idle mode? I have some routines that wait for serial data etc and in the vPreSleepProcessing I call the RTC to a one second sleep so probably thats why it keeps on going in sleep.
How can I force using a sleep only when needed for example when vTaskDelay is called? using the xExpectedIdleTime parameter?

Nick

rtel wrote on Thursday, August 01, 2013:

Why can’t you use the debugger?  I would have thought it almost essential.

Does vPreSleepProcessing get called when vTaskDelay is called or as well when tasks are in idle mode?

The only path to calling the pre-sleep processing macro is when the idle task is running and there are no other tasks due to execute within the configurable configEXPECTED_IDLE_TIME_BEFORE_SLEEP time frame.

The pre-sleep processing is not directly called because you have used vTaskDelay(), but it could be indirectly called if putting the task that called vTaskDelay() into the Blocked state resulted in the idle task running (because there were no other Ready state tasks), and the idle task determined that there were no other tasks due to execute within the configEXPECTED_IDLE_TIME_BEFORE_SLEEP time frame.

From your description I’m not sure what you are doing with the RTC in the pre-sleep processing macro.  If you want to bring the CPU out of sleep after one second then an interrupt should be configured to do that before the pre-sleep processing is called.  Also, are your serial ports handled by interrupts?  If so then the CPU will be brought out of sleep mode automatically when there is a serial port interrupt, so it might not be necessary to set a 1 second wake up anyway.  Without in-depth knowledge of your hardware and application I don’t know for sure - just putting out some suggestions.

Regards.

liaochengyi wrote on Friday, December 27, 2013:

Hi,

My I ask how to determine the value of “configEXPECTED_IDLE_TIME_BEFORE_SLEEP”
The default value is “2”, is it depend on the task number?

Thanks a lot!

rtel wrote on Friday, December 27, 2013:

That constant is configuration to allow you to tune the behaviour to your specific system, so how the value is determined is up to you.

If the power modes you are using take a long time to exit (for the clock to spin up to speed again, for peripherals to be powered up, for the flash to be powered up, etc.) then you will want to use a longer value to ensure you are not consuming more power exiting sleep mode than you are saving by entering it in the first place.

If you system sleeps for months at a time and only occasionally wakes for a burst of activity the you can set a long timer.

Etc.

Regards.

liaochengyi wrote on Friday, December 27, 2013:

Hi,

My I ask how to determine the value of
“xMaximumPossibleSuppressedTicks”

Thanks a lot!

liaochengyi wrote on Sunday, December 29, 2013:

Hi,

My I ask how to determine the value of
“xMaximumPossibleSuppressedTicks”

If my task has not interrupt, how the slept system weak up?
Thanks a lot!

rtel wrote on Sunday, December 29, 2013:

It is the maximum number of tick periods that can be counted in your timer before the timer overflows. Its value is therefore dependent on the width of the timer’s counter in bits and the timer’s frequency.

In the generic tickless implementation which uses the Cortex-M SysTick timer (which is only 24-bits) then you can see it being calculated as follows:

First work out how many SysTick timer increments are required to generate one tick period by dividing the timer’s frequency specified in Hz by the tick rate specified in Hz:
ulTimerCountsForOneTick = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ );

Then see how many times the timer can count the resultant number before the timer overflows - which in this case is how many times ulTimerCountsForOneTick will fit into the SysTick timer’s 24-bit counter register:
xMaximumPossibleSuppressedTicks = portMAX_24_BIT_NUMBER / ulTimerCountsForOneTick;

Therefore, the timer can be used to generate an interrupt xMaximumPossibleSuppressedTicks tick periods into the future because xMaximumPossibleSuppressedTicks * ulTimerCountsForOneTick will fit into the 24-bit number.

You can see then that the SysTick timer is not capable of allowing extended tickless periods because it is limited to only 24-bits and a fast time input. Therefore tickless implementations that are tailored to a specific chips will ideally use a slow clock (32Khz is common) and a 32-bit timer - allowing tickless periods that extend into months rather than fractions of a second.

Regards.