Memory usage monitoring in FreeRTOS - Step-by-Step Execution

Concept Flow - Memory usage monitoring

Start System

↓

Initialize Memory

↓

Allocate Memory

↓

Monitor Usage

↓

Check Threshold

↓

Alert

↓

Free Memory

↓

Repeat Monitoring

This flow shows how FreeRTOS monitors memory: system starts, memory is allocated, usage is checked, alerts trigger if limits exceeded, then memory is freed and monitoring repeats.

Execution Sample

FreeRTOS

size_t freeHeap = xPortGetFreeHeapSize();
if (freeHeap < threshold) {
  notifyLowMemory();
}
// Continue normal operation

This code checks the free heap memory and triggers a notification if it falls below a set threshold.

Execution Table

Step	Action	Free Heap Size (bytes)	Condition (freeHeap < threshold)	Result
1	System starts, heap initialized	10000	10000 < 2000 ?	False, continue
2	Allocate 3000 bytes	7000	7000 < 2000 ?	False, continue
3	Allocate 4000 bytes	3000	3000 < 2000 ?	False, continue
4	Allocate 1500 bytes	1500	1500 < 2000 ?	True, notify low memory
5	Free 1000 bytes	2500	2500 < 2000 ?	False, continue
6	Allocate 600 bytes	1900	1900 < 2000 ?	True, notify low memory
7	Free 900 bytes	2800	2800 < 2000 ?	False, continue
8	Monitoring cycle repeats	2800	2800 < 2000 ?	False, continue

💡 Monitoring continues indefinitely, alerts sent when free heap falls below threshold

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	Final
freeHeap	10000	7000	3000	1500	2500	1900	2800	2800

Key Moments - 3 Insights

Why does the system notify low memory at step 4 but not at step 3?

At step 3, freeHeap is 3000 which is not less than the threshold 2000, so no alert. At step 4, freeHeap drops to 1500 which is below threshold, triggering notification (see execution_table rows 3 and 4).

What happens if memory is freed after a low memory alert?

Freeing memory increases freeHeap above threshold, so subsequent checks do not trigger alerts (see step 5 and 7 in execution_table).

Does monitoring stop after a low memory alert?

No, monitoring continues indefinitely, checking memory repeatedly and alerting whenever freeHeap is below threshold (see exit_note and repeated steps).

Visual Quiz - 3 Questions

Look at the execution table, what is the freeHeap value at step 4?

A 3000

B 7000

C 1500

D 1900

💡 Hint

Check the 'Free Heap Size (bytes)' column at step 4 in the execution_table.

At which step does the condition freeHeap < threshold first become true?

A Step 3

B Step 4

C Step 6

D Step 2

💡 Hint

Look at the 'Condition' column in execution_table and find the first 'True' value.

If the threshold was lowered to 1000, at which step would the first low memory alert occur?

A No alert would occur

B Step 4

C Step 8

D Step 6

💡 Hint

Compare freeHeap values with new threshold 1000 in execution_table rows.

Concept Snapshot

Memory Usage Monitoring in FreeRTOS:
- Use xPortGetFreeHeapSize() to get free heap memory.
- Compare free heap with a threshold.
- If below threshold, trigger alert (e.g., notifyLowMemory()).
- Free memory when possible to recover.
- Repeat monitoring continuously to avoid memory exhaustion.

Full Transcript

This visual execution trace shows how FreeRTOS monitors memory usage. The system starts with a free heap of 10000 bytes. As memory is allocated, free heap decreases. Each step checks if free heap is below a threshold (2000 bytes). When it is, a low memory notification is triggered. Freeing memory increases free heap and stops alerts until it falls below threshold again. Monitoring repeats indefinitely to keep the system stable.

Practice

1. What is the primary purpose of memory usage monitoring in FreeRTOS?

easy

A. To keep the system stable by tracking free stack space

B. To increase CPU clock speed automatically

C. To disable unused tasks permanently

D. To reduce the size of the kernel

Solution

1. Step 1: Understand memory monitoring role

   Memory usage monitoring helps detect low memory conditions to avoid crashes.

2. Step 2: Identify the main goal in FreeRTOS

   Tracking free stack space per task ensures system stability and prevents overflow.

3. Final Answer:

   To keep the system stable by tracking free stack space -> Option A

4. Quick Check:

   Memory monitoring = system stability [OK]

Hint: Memory monitoring prevents crashes by tracking stack space [OK]

Common Mistakes:

• Confusing memory monitoring with CPU speed control
• Thinking it disables tasks automatically
• Assuming it reduces kernel size

2. Which FreeRTOS function is used to check the minimum amount of stack space left for a task?

easy

A. uxTaskGetStackHighWaterMark()

B. vTaskDelete()

C. xTaskCreate()

D. vTaskDelay()

Solution

1. Step 1: Identify stack monitoring function

   uxTaskGetStackHighWaterMark() returns the minimum free stack space for a task.

2. Step 2: Differentiate from other task functions

   Other functions manage tasks but do not report stack usage.

3. Final Answer:

   uxTaskGetStackHighWaterMark() -> Option A

4. Quick Check:

   Stack check function = uxTaskGetStackHighWaterMark() [OK]

Hint: Stack water mark means free stack space left [OK]

Common Mistakes:

• Choosing task creation or deletion functions
• Confusing delay function with memory check

3. Given the code snippet:

UBaseType_t freeStack = uxTaskGetStackHighWaterMark(NULL);
printf("Free stack: %u\n", freeStack);

What does this code output?

medium

A. The total stack size of the current task

B. The current CPU usage percentage

C. The minimum free stack space left in the current task

D. The number of tasks running

Solution

1. Step 1: Analyze uxTaskGetStackHighWaterMark(NULL)

   Passing NULL gets the current task's minimum free stack space since start.

2. Step 2: Understand printf output

   It prints the free stack space value, not total stack or CPU info.

3. Final Answer:

   The minimum free stack space left in the current task -> Option C

4. Quick Check:

   NULL param = current task stack free space [OK]

Hint: NULL means current task in FreeRTOS stack check [OK]

Common Mistakes:

• Thinking it returns total stack size
• Confusing with task count or CPU usage

4. You wrote this code to monitor stack usage:

UBaseType_t freeStack = uxTaskGetStackHighWaterMark(taskHandle);
if(freeStack == 0)
{
  printf("Stack overflow detected!\n");
}

But it never prints the warning even when the system crashes. What is the likely issue?

medium

A. Using taskHandle instead of NULL for current task

B. Checking for zero instead of a low threshold

C. Not calling vTaskStartScheduler() before monitoring

D. Using printf instead of a logging function

Solution

1. Step 1: Understand uxTaskGetStackHighWaterMark() return

   It returns minimum free stack space, zero means no free space left.

2. Step 2: Check condition logic

   Waiting for exactly zero misses low free space warnings; better to check below a threshold.

3. Final Answer:

   Checking for zero instead of a low threshold -> Option B

4. Quick Check:

   Zero check misses low stack warnings [OK]

Hint: Check for low stack threshold, not just zero [OK]

Common Mistakes:

• Assuming zero is the only danger point
• Confusing taskHandle usage
• Blaming printf for missing output

5. You want to monitor stack usage for multiple tasks and log warnings if any task's free stack falls below 50 words. Which approach is best?

hard

A. Call uxTaskGetStackHighWaterMark(NULL) once and assume all tasks are safe

B. Increase total heap size instead of monitoring stack

C. Only monitor the highest priority task's stack usage

D. Loop through all task handles, call uxTaskGetStackHighWaterMark(), compare to 50, log if below

Solution

1. Step 1: Understand monitoring multiple tasks

   Each task has its own stack; checking all ensures no task is overlooked.

2. Step 2: Implement threshold check per task

   Looping through tasks and comparing free stack to 50 words allows targeted warnings.

3. Step 3: Evaluate other options

   Checking only current or highest priority task misses others; increasing heap doesn't solve stack issues.

4. Final Answer:

   Loop through all task handles, call uxTaskGetStackHighWaterMark(), compare to 50, log if below -> Option D

5. Quick Check:

   Check all tasks individually for stack [OK]

Hint: Check each task's stack individually for accurate monitoring [OK]

Common Mistakes:

• Assuming one check covers all tasks
• Ignoring lower priority tasks
• Confusing heap size with stack size