Memory usage monitoring in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Interpreting FreeRTOS heap_4 memory usage output

Given the FreeRTOS heap_4 memory scheme, what does the following output from xPortGetFreeHeapSize() indicate?

FreeRTOS

size_t freeHeap = xPortGetFreeHeapSize();
printf("Free heap size: %u bytes\n", (unsigned int)freeHeap);

A It shows the total free heap memory available for allocation at runtime.

B It shows the total heap memory used by all tasks combined.

C It shows the maximum heap size configured in FreeRTOSConfig.h.

D It shows the stack size of the currently running task.

💡 Hint

Think about what 'free heap size' means in memory management.

The function xPortGetFreeHeapSize() returns the amount of heap memory currently free and available for allocation. It does not show used memory or stack sizes.

🧠 Conceptual

intermediate

Understanding stack overflow detection in FreeRTOS

Which FreeRTOS feature helps detect stack overflow in tasks during runtime?

A Enabling configUSE_IDLE_HOOK to check stack limits.

B Using xPortGetFreeHeapSize() to monitor stack usage.

C configCHECK_FOR_STACK_OVERFLOW set to 1 or 2 enables stack overflow checking.

D Setting configMAX_PRIORITIES to a higher value.

💡 Hint

Look for configuration options related to stack overflow.

FreeRTOS can detect stack overflow if configCHECK_FOR_STACK_OVERFLOW is set to 1 or 2. This enables runtime checks to catch stack overflows.

❓ Troubleshoot

advanced

Diagnosing unexpected heap exhaustion in FreeRTOS

A FreeRTOS system using heap_4 suddenly runs out of heap memory causing task creation failures. Which of the following is the most likely cause?

A configUSE_PREEMPTION set to 0.

B Memory fragmentation due to many small allocations and frees.

C Using xTaskGetTickCount() incorrectly.

D Stack overflow in the idle task.

💡 Hint

Think about how heap_4 manages memory blocks.

Heap_4 uses malloc and free with coalescing but can still suffer fragmentation if many small allocations and frees happen, leading to heap exhaustion.

🔀 Workflow

advanced

Steps to monitor FreeRTOS task stack usage at runtime

What is the correct sequence of steps to monitor the stack usage of a FreeRTOS task during runtime?

A 4,3,2,1

B 2,1,3,4

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about how to get data, interpret it, then act on it.

The function uxTaskGetStackHighWaterMark() returns the minimum amount of stack space that remained unused. Comparing it to the total stack size helps detect overflow risks.

✅ Best Practice

expert

Best practice for minimizing heap fragmentation in FreeRTOS

Which approach best minimizes heap fragmentation when using FreeRTOS heap_4 memory scheme in a long-running embedded system?

A Use fixed-size memory pools for dynamic allocations instead of malloc/free.

B Increase configTOTAL_HEAP_SIZE to maximum possible value.

C Disable stack overflow checking to reduce overhead.

D Use heap_1 scheme instead of heap_4.

💡 Hint

Think about avoiding fragmentation by controlling allocation sizes.

Using fixed-size memory pools avoids fragmentation because allocations and frees are uniform and predictable, unlike malloc/free which can fragment heap.

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