Starting and stopping timers in FreeRTOS - Deep Dive

Overview - Starting and stopping timers

What is it?

Starting and stopping timers in FreeRTOS means controlling when a timer begins counting and when it stops. Timers in FreeRTOS are software tools that help run code after a delay or repeatedly at set intervals. You can start a timer to trigger an action later, and stop it if you no longer want that action to happen. This helps manage tasks that need to happen on time without blocking other work.

Why it matters

Without the ability to start and stop timers, your program would struggle to handle timed events efficiently. You might waste resources waiting or miss important actions that should happen at precise moments. Timers let your system be responsive and organized, like setting alarms or reminders in daily life. Without them, managing time-based tasks would be chaotic and error-prone.

Where it fits

Before learning about starting and stopping timers, you should understand basic FreeRTOS concepts like tasks and queues. After this, you can explore advanced timer features like timer callbacks, auto-reload timers, and timer synchronization with tasks. This topic fits into managing time and events in embedded systems programming.

Mental Model

Core Idea

Starting a timer sets a countdown to trigger an action later, and stopping it cancels that countdown before it finishes.

Think of it like...

Imagine setting a kitchen timer to remind you when your food is ready. Starting the timer means you begin counting down, and stopping it means you cancel the reminder before it rings.

┌───────────────┐       start()        ┌───────────────┐
│ Timer Created │ ───────────────────▶ │ Timer Running │
└───────────────┘                      └───────────────┘
       ▲                                      │
       │                                      │ stop()
       │                                      ▼
┌───────────────┐                      ┌───────────────┐
│ Timer Stopped │ ◀────────────────── │ Timer Running │
└───────────────┘                      └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a FreeRTOS timer?

Concept: Introduce the basic idea of a software timer in FreeRTOS.

A FreeRTOS timer is a software object that counts time in the background. When the timer expires, it runs a function called a callback. Timers can be one-shot (run once) or auto-reload (run repeatedly). They help schedule actions without blocking the main program.

Result

You understand that timers are tools to run code after delays or repeatedly.

Knowing timers are software objects that run code later helps you see how FreeRTOS manages time without stopping other tasks.

2

Foundation

Creating a timer in FreeRTOS

Concept: Learn how to create a timer with a name, period, and callback function.

Use xTimerCreate() to make a timer. You give it a name, the time period in ticks, a flag for auto-reload, an ID, and a callback function. The timer is created but not running yet.

Result

You have a timer object ready to start but it does nothing until started.

Understanding creation separates setup from running, so you can prepare timers before using them.

3

Intermediate

Starting a timer with xTimerStart()

🤔Before reading on: do you think starting a timer immediately runs its callback or waits for the period? Commit to your answer.

Concept: Starting a timer begins its countdown but does not run the callback immediately.

Call xTimerStart(timerHandle, blockTime) to start the timer. The timer counts down in the background. When the period ends, the callback runs. blockTime is how long the call waits if the timer command queue is full.

Result

The timer begins counting down and will trigger the callback after the set period.

Knowing the callback runs only after the countdown prevents confusion about immediate effects of starting timers.

4

Intermediate

Stopping a timer with xTimerStop()

🤔Before reading on: do you think stopping a timer immediately runs its callback or cancels it? Commit to your answer.

Concept: Stopping a timer cancels the countdown and prevents the callback from running if it hasn't already.

Call xTimerStop(timerHandle, blockTime) to stop the timer. If the timer is running, it stops counting down. The callback will not run unless the timer is started again.

Result

The timer stops and no callback happens unless restarted.

Understanding stopping cancels pending callbacks helps avoid unexpected actions in your program.

5

Intermediate

Using auto-reload timers for repeated actions

Concept: Auto-reload timers restart automatically after each period, running callbacks repeatedly.

When creating a timer, set the auto-reload flag to pdTRUE. After the timer expires and runs the callback, it resets and starts counting again. You can stop it anytime to end the cycle.

Result

The timer triggers its callback repeatedly at fixed intervals until stopped.

Knowing auto-reload timers automate repeated tasks reduces the need for manual restarts.

6

Advanced

Handling timer commands and block times

🤔Before reading on: do you think blockTime in xTimerStart() blocks your whole program or just the timer command? Commit to your answer.

Concept: blockTime controls how long the function waits to send a command to the timer service task, not the whole program.

FreeRTOS timers use a timer service task to manage timers. When you start or stop a timer, a command is sent to this task. blockTime is how long your call waits if the command queue is full. Your program continues running while the timer counts down.

Result

You avoid blocking your main tasks when starting or stopping timers, improving responsiveness.

Understanding the timer service task and command queue prevents confusion about delays caused by timer operations.

7

Expert

Race conditions and timer state management

🤔Before reading on: do you think starting a timer twice causes two callbacks or just one? Commit to your answer.

Concept: Starting a timer that is already running resets its countdown; stopping a timer that is not running has no effect.

If you call xTimerStart() on a running timer, the countdown restarts from zero. This can prevent multiple callbacks stacking up. Stopping a timer that is not running returns an error but does not crash. Properly managing timer states avoids race conditions and unexpected behavior.

Result

Your program handles timers safely without duplicate or missed callbacks.

Knowing how FreeRTOS handles repeated start/stop calls helps prevent subtle bugs in timing logic.

Under the Hood

FreeRTOS timers are managed by a dedicated timer service task. When you start or stop a timer, a command is sent to this task via a queue. The timer service task tracks all active timers and decrements their countdowns based on the system tick. When a timer expires, the service task calls the timer's callback function in its own context. This design avoids blocking other tasks and centralizes timer management.

Why designed this way?

This design separates timer management from application tasks to keep timing accurate and efficient. Using a timer service task avoids race conditions and reduces complexity in user tasks. Alternatives like hardware timers or blocking delays were less flexible or blocked CPU time. The queue-based command system allows safe communication between tasks and the timer service.

┌───────────────┐       Commands       ┌────────────────────┐
│ Application   │ ───────────────────▶ │ Timer Service Task │
│ Tasks         │                      │ (manages timers)   │
└───────────────┘                      └─────────┬──────────┘
                                                │
                                                │ Calls callback when timer expires
                                                ▼
                                       ┌────────────────────┐
                                       │ Timer Callback Func │
                                       └────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does stopping a timer immediately run its callback? Commit to yes or no.

Common Belief: Stopping a timer runs its callback immediately to clean up.

Reality: Stopping a timer cancels the countdown and prevents the callback from running unless restarted.

Why it matters: Believing callbacks run on stop can cause unexpected code execution and bugs.

Quick: If you start a timer twice quickly, do you get two callbacks or one? Commit to your answer.

Common Belief: Starting a timer twice queues two callbacks, causing duplicate actions.

Reality: Starting a running timer resets its countdown; only one callback will occur after the new period.

Why it matters: Misunderstanding this leads to redundant or missed timer events in your program.

Quick: Does xTimerStart() block your entire program until the timer expires? Commit to yes or no.

Common Belief: Starting a timer blocks the program until the timer finishes counting down.

Reality: Starting a timer only sends a command to the timer service task and returns quickly; the program continues running.

Why it matters: Thinking timers block execution can cause inefficient or incorrect program designs.

Quick: Can a timer callback run in the context of your main task? Commit to yes or no.

Common Belief: Timer callbacks run in the task that started the timer.

Reality: Timer callbacks run in the timer service task context, separate from application tasks.

Why it matters: Assuming callbacks run in your task can cause synchronization bugs and unsafe code.

Expert Zone

1

Starting a timer that is already running resets its countdown instead of creating a new timer instance.

2

Timer callbacks run in the timer service task context, so they must be short and non-blocking to avoid delaying other timers.

3

The blockTime parameter in timer commands only affects how long the command waits to enter the timer queue, not the timer countdown itself.

When NOT to use

FreeRTOS software timers are not suitable for very high precision timing or very short delays due to tick granularity and task scheduling. For such cases, hardware timers or dedicated peripherals should be used instead.

Production Patterns

In real systems, timers are used to debounce buttons, trigger periodic sensor reads, or implement timeouts. Developers often combine timers with queues or event groups to synchronize actions safely. Careful management of timer start/stop calls prevents race conditions and resource leaks.

Connections

Event-driven programming

Timers trigger events after delays, fitting into event-driven design patterns.

Understanding timers as event triggers helps grasp how asynchronous systems manage time-based actions.

Operating system schedulers

Timer service task scheduling is similar to how OS schedulers manage task execution order.

Knowing OS scheduling principles clarifies why timer callbacks run in a separate task context.

Project management deadlines

Starting and stopping timers is like setting and canceling deadlines in project tasks.

Seeing timers as deadlines helps relate software timing to real-world time management challenges.

Common Pitfalls

#1 Starting a timer without checking if it is already running causes unexpected resets.

Wrong approach:

xTimerStart(myTimer, 0);
xTimerStart(myTimer, 0);

Correct approach:

if (xTimerIsTimerActive(myTimer) == pdFALSE) {
xTimerStart(myTimer, 0);
}

Root cause:

Not understanding that starting a running timer resets its countdown leads to unintended behavior.

#2 Running long or blocking code inside a timer callback delays other timers.

Wrong approach:

void TimerCallback(TimerHandle_t xTimer) {
vTaskDelay(pdMS_TO_TICKS(1000)); // blocks for 1 second
}

Correct approach:

void TimerCallback(TimerHandle_t xTimer) {
// Set a flag or notify a task to handle long work
}

Root cause:

Misunderstanding that timer callbacks run in the timer service task causes performance issues.

#3 Using zero blockTime in xTimerStart() without ensuring the timer queue is free causes command failures.

Wrong approach:

xTimerStart(myTimer, 0); // may fail if queue is full

Correct approach:

xTimerStart(myTimer, pdMS_TO_TICKS(10)); // waits up to 10ms to send command

Root cause:

Ignoring blockTime risks commands being dropped silently, leading to timers not starting.

Key Takeaways

FreeRTOS timers let you schedule code to run later or repeatedly without blocking your program.

Starting a timer begins its countdown; stopping it cancels the countdown and prevents the callback.

Timer callbacks run in a special timer service task, so they must be quick and non-blocking.

Starting a running timer resets its countdown instead of creating multiple timers.

Understanding timer commands and block times helps avoid subtle bugs and performance issues.

Practice

1. What does the function xTimerCreate do in FreeRTOS?

easy

A. Creates a timer but does not start it automatically

B. Starts a timer immediately after creation

C. Stops a running timer

D. Deletes a timer permanently

Solution

1. Step 1: Understand the purpose of xTimerCreate

   This function is used to create a software timer in FreeRTOS but it does not start the timer automatically.

2. Step 2: Differentiate from other timer functions

   Starting a timer requires xTimerStart, stopping requires xTimerStop, and deleting requires xTimerDelete.

3. Final Answer:

   Creates a timer but does not start it automatically -> Option A

4. Quick Check:

   xTimerCreate only creates timer [OK]

Hint: Remember: create ≠ start; start needs separate call [OK]

Common Mistakes:

• Thinking xTimerCreate starts the timer automatically
• Confusing xTimerStart with creation
• Assuming timer is running immediately after creation

2. Which of the following is the correct way to start a FreeRTOS timer named xTimer?

easy

A. xTimerDelete(xTimer, 0);

B. xTimerCreate(xTimer, 0);

C. xTimerStop(xTimer, 0);

D. xTimerStart(xTimer, 0);

Solution

1. Step 1: Identify the function to start a timer

   The function xTimerStart is used to start a timer in FreeRTOS.

2. Step 2: Check the syntax

   The correct syntax is xTimerStart(xTimer, 0); where the second parameter is the block time.

3. Final Answer:

   xTimerStart(xTimer, 0); -> Option D

4. Quick Check:

   Start timer = xTimerStart call [OK]

Hint: Start timers with xTimerStart, not create or stop [OK]

Common Mistakes:

• Using xTimerCreate to start a timer
• Confusing stop and delete functions with start
• Missing the block time parameter

3. Given the following code snippet, what will be the output if the timer callback increments a counter each time it runs and the timer is started and stopped immediately?

int counter = 0;
TimerHandle_t xTimer = xTimerCreate("Timer", pdMS_TO_TICKS(1000), pdTRUE, NULL, timerCallback);
xTimerStart(xTimer, 0);
xTimerStop(xTimer, 0);
// Assume timerCallback increments counter

medium

A. counter will remain 0

B. counter will be incremented at least once

C. Compilation error due to missing parameters

D. Runtime error due to invalid timer handle

Solution

1. Step 1: Analyze timer start and stop sequence

   The timer is started and then immediately stopped before it can expire and call the callback.

2. Step 2: Understand timer callback execution

   Since the timer period is 1000 ms and it is stopped immediately, the callback does not get a chance to run, so the counter stays 0.

3. Final Answer:

   counter will remain 0 -> Option A

4. Quick Check:

   Immediate stop prevents callback = counter 0 [OK]

Hint: Timer callback runs only after timer expires, not immediately [OK]

Common Mistakes:

• Assuming callback runs immediately on start
• Ignoring timer period delay
• Confusing start and stop timing effects

4. Identify the error in the following code snippet that attempts to stop a timer:

TimerHandle_t xTimer = xTimerCreate("Timer", pdMS_TO_TICKS(500), pdFALSE, NULL, timerCallback);
xTimerStop(xTimer, 1000);

medium

A. The block time parameter in xTimerStop is too large

B. The timer was never started before stopping

C. The timer handle is NULL

D. The timer period is set incorrectly

Solution

1. Step 1: Check timer lifecycle

   The timer is created but never started before calling xTimerStop.

2. Step 2: Understand stopping a timer

   Stopping a timer that is not running has no effect and may cause unexpected behavior.

3. Final Answer:

   The timer was never started before stopping -> Option B

4. Quick Check:

   Stop requires running timer first [OK]

Hint: Always start timer before stopping it [OK]

Common Mistakes:

• Stopping timer without starting it
• Assuming block time causes error
• Misunderstanding timer handle validity

5. You want to create a periodic timer in FreeRTOS that starts automatically and stops after 5 executions. Which approach correctly achieves this behavior?

hard

A. Create the timer with pdTRUE, start it automatically by xTimerCreate, and delete after 5 executions

B. Create the timer with pdFALSE, start it manually, and stop it after 5 seconds

C. Create the timer with pdTRUE for auto-reload, start it manually, and in the callback count executions and stop after 5

D. Create the timer with pdFALSE, start it automatically, and restart it 5 times

Solution

1. Step 1: Understand timer creation parameters

   Setting pdTRUE makes the timer periodic (auto-reload), but it does not start automatically; you must call xTimerStart.

2. Step 2: Implement stopping after 5 executions

   Use a counter inside the callback function to track executions and call xTimerStop after the 5th execution.

3. Final Answer:

   Create the timer with pdTRUE for auto-reload, start it manually, and in the callback count executions and stop after 5 -> Option C

4. Quick Check:

   Periodic timer + manual start + callback stop after 5 [OK]

Hint: Use callback counter to stop periodic timer after N runs [OK]

Common Mistakes:

• Assuming xTimerCreate starts timer automatically
• Using one-shot timer for periodic behavior
• Not counting executions in callback