How software timers works with respect to tick interrupt?

Value of configTICK_RATE_HZ was 100, the tick interrupt occur at every 10ms. Here software timer of 10 ms was created.
After scheduler was started,

1. At every tick interrupt occurs, the calllback function mentioned for the specific timer was called?

2. At every tick interrupt, before time interrupt tend to happen, with the tolerance of some value, software timer(Assume timer are high priority) will be called. I tried to understood the timer with tick interrupt in following way. Say for example, after scheduler was started, counter variable starts incrementing from 0. After the value reached 10, timer callback function called?

3. With the tick interrupt occurs at every 10ms, I created the timer of 20ms. In that case at the second tick interrupt occurs from the scheduler started condition, the timer of 20 ms will be started right?

4. With the tick interrupt occurs at every 10ms, I created the timer of 15ms. In that case, the timer was called at every 10 ms itself, but i set the timer to start at every 15ms interval. How this case was not achieved ? so for the timer value set while creating the software timer, it should be the multiple of tick interrupt?

5. Is there any tolerance was acceptable/set for the software timer to call at exact time?

Mainly i want to understood, how timers works with respect to the tick interrupt.
Could you explain more about how software timers works?

rtel wrote on Thursday, October 24, 2019:

Value of configTICK_RATE_HZ was 100, the tick interrupt occur at every
10ms. Here software timer of 10 ms was created.
After scheduler was started,

1. At every tick interrupt occurs, the calllback function mentioned for
the specific timer was called?

Not sure if that is a question, but yes that is the expected behaviour.

1. At every tick interrupt, before time interrupt tend to happen, with
the tolerance of some value, software timer(Assume timer are high
priority) will be called. I tried to understood the timer with tick
interrupt in following way. Say for example, after scheduler was
started, counter variable starts incrementing from 0. After the value
reached 10, timer callback function called?
2. With the tick interrupt occurs at every 10ms, I created the timer of
20ms. In that case at the second tick interrupt occurs from the
scheduler started condition, the timer of 20 ms will be started right?

No, see “Efficiency considerations in software timer implementations” on
the following page: https://www.freertos.org/RTOS-software-timer.html

Suggest looking at the timers.c source file and stepping through the
code in the debugger. Software timers execute in the timer/daemon task
(two names for the same thing) and that task functions just like any
other task under the control of FreeRTOS - basically it enters the
Blocked state until the time the next timer expires.

1. With the tick interrupt occurs at every 10ms, I created the timer of
15ms. In that case, the timer was called at every 10 ms itself, but i
set the timer to start at every 15ms interval. How this case was not
achieved ?

All time is measured in ticks, so if time increments every 10ms you only
have a time granularity of 10ms - hence asking for 15ms will result in a
truncation to the nearest measurable time interval - again you can see
this happening in the code. Also recommend taking a look at the
following resources https://www.freertos.org/Documentation/RTOS_book.html

Hi Richard, Thank you so much for the detailed reply.

Here are few doubts:

1. How the timers of microseconds was achieved in software timers?

2. In the documentation, I read of content of software timer as follows:
“Software timers are implemented by, and are under the control of, the FreeRTOS kernel. They do not require hardware support, and are not related to hardware timers or hardware counters.”
But while generating the code via stmcubemx, we choosed the timebase source in sys tab of “System core” as “TMR 6” instead of “systick”. Here software timer actually uses one of the hardware timer right?

Which of timebase source used by Tick interrupt generally?

rtel wrote on Friday, October 25, 2019:

Here are few doubts:

1. How the timers of microseconds was achieved in software timers?

Generally you can’t, you would have to use a hardware timer to get that
resolution, and generally that resolution would not be required for a
timeout value used by a task. If you need very high precision, say for
motor control, then you can use a hardware timer or other source of
interrupt (hall sensor input or whatever) and perform the processing
inside the interrupt handler - making sure the priority of the interrupt
is above configMAX_SYSCALL_INTERRUPT_PRIORITY so the interrupt remains
enabled at all times.

1. In the documentation, I read of content of software timer as follows:
“Software timers are implemented by, and are under the control of, the
FreeRTOS kernel. They do not require hardware support, and are not
related to hardware timers or hardware counters.”
But while generating the code via stmcubemx, we choosed the timebase
source in sys tab of “System core” as “TMR 6” instead of “systick”. Here
software timer actually uses one of the hardware timer right?

The hardware timer is used to generate the RTOS tick interrupt, which is
used by the kernel to unblock tasks at the correct time. Software
timers execute in the context of a task - so software timers have no

Hi Richard,

Thanks for response.
With respect to testing, i want the tolerance of execution of then timer callback function of software timer.
In case of tick interrupt runs at 10ms, I created the timer of 10ms. In that case, when the timer reaches exactly 10ms(tick interrupt generated), the timer callback function will be executed or at callback function will be executed at 9.xx ms or 10.xx ms?

rtel wrote on Wednesday, October 30, 2019:

On each tick interrupt the scheduler decides which task to run - which
is always the highest priority task that is ready to run (this is not
the only time the scheduler runs, task switches occur between tick
interrupts too). The priority of the timer task, in which timer
callback functions execute, is set in FreeRTOSConfig.h, and the timer
task is scheduled like any other task. So if a tick interrupt occurs
which makes a software time expire, which in turn moves the timer task
from the blocked state to the ready state, and at that time the timer
task is the highest priority task, then the tick interrupt will return
directly to the timer task where the software timer callback will execute.

Thanks Richard for the detailed response

One more thing to note. In FreeRTOS ALL time periods are specified in Ticks, and on most machines Ticks are very tightly controlled at the timer level. Delays and such have several things that can affect them. First is a quantization effect. When you start a time or initiate a del ay/timeout, you might be anywhere within the tick period. Thus a delay of 1 tick might be a full tick period, if the tick interrupt just occured, or it may be a very short time if the tick interrupt is about to happen. In addition, the delay might be extended due to higher priority tasks running when this task should restart.

This means that I rarely use a 1 tick delay (except for vTaskDelayUntil) if I really need a delay for a given time (I might use it for a polling loop where I just want to give other tasks some time to run before checking again). If you need a delay that will be at least 1 tick period, you need to delay for 2 ticks