Critical sections and interrupt disabling in FreeRTOS - Step-by-Step Execution

Concept Flow - Critical sections and interrupt disabling

Start Task

↓

Disable Interrupts

↓

Enter Critical Section

↓

Execute Critical Code

↓

Exit Critical Section

↓

Enable Interrupts

↓

Continue Task Execution

The task disables interrupts to enter a critical section, runs code safely, then re-enables interrupts to continue.

Execution Sample

FreeRTOS

taskENTER_CRITICAL();
// Critical code here
taskEXIT_CRITICAL();

This code disables interrupts to protect critical code, then re-enables interrupts after.

Execution Table

Step	Action	Interrupt State	Description
1	Call taskENTER_CRITICAL()	Disabled	Interrupts disabled, entering critical section
2	Execute critical code	Disabled	Critical code runs safely without interruption
3	Call taskEXIT_CRITICAL()	Enabled	Interrupts re-enabled, exiting critical section
4	Continue normal task	Enabled	Task continues with interrupts enabled

💡 Interrupts re-enabled after critical section, allowing normal operation

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Interrupts	Enabled	Disabled	Disabled	Enabled	Enabled
InCriticalSection	False	True	True	False	False

Key Moments - 3 Insights

Why do interrupts need to be disabled in a critical section?

Interrupts are disabled (see Step 1 in execution_table) to prevent other code from interrupting and causing data corruption during the critical code execution.

What happens if interrupts are not re-enabled after the critical section?

If interrupts stay disabled (not shown in Step 3), the system cannot respond to important events, causing system malfunction or freezes.

Can critical sections be nested?

Yes, FreeRTOS supports nesting by counting entries; interrupts are only re-enabled after the last taskEXIT_CRITICAL() call (not shown in this simple trace).

Visual Quiz - 3 Questions

Look at the execution_table, what is the interrupt state during Step 2?

A Enabled

B Partially enabled

C Disabled

D Unknown

💡 Hint

Check the 'Interrupt State' column for Step 2 in the execution_table.

At which step are interrupts re-enabled?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look for 'taskEXIT_CRITICAL()' in the Action column and see the Interrupt State change.

If interrupts were not disabled at Step 1, what risk would occur?

A Task would run faster

B Critical code might be interrupted causing data corruption

C System would disable itself

D No effect

💡 Hint

Refer to the key_moments explanation about why interrupts are disabled.

Concept Snapshot

taskENTER_CRITICAL() disables interrupts to protect critical code.
taskEXIT_CRITICAL() re-enables interrupts after.
Use critical sections to avoid data corruption.
Interrupts must be re-enabled to keep system responsive.
Nesting is supported by FreeRTOS internally.

Full Transcript

In FreeRTOS, critical sections protect code from interruption by disabling interrupts using taskENTER_CRITICAL(). This ensures the critical code runs safely without interference. After the critical code finishes, taskEXIT_CRITICAL() re-enables interrupts so the system can respond to events again. Interrupts start enabled, get disabled at Step 1, stay disabled during critical code at Step 2, and are re-enabled at Step 3. If interrupts were not disabled, other code could interrupt and cause data corruption. Also, interrupts must be re-enabled after the critical section to avoid system freezes. FreeRTOS supports nested critical sections by counting entries and only enabling interrupts after the last exit call.