Analyzing ESP-IDF System Performance

1. Visualizing Your System with Segger SystemView

One of the most powerful tools at our disposal is Segger SystemView. It provides a real-time, graphical visualization of your application's behavior. Instead of guessing what your tasks are doing, you can see it unfold on a timeline.

SystemView works by leveraging the Application Level Tracing library in ESP-IDF. Your ESP32 sends a stream of events (like "Task A started running," "Queue received a message," "ISR entered") over a JTAG connection to your computer. A tool called OpenOCD captures this data, and SystemView visualizes it.

Setting Up and Capturing a Trace

The process involves configuring your project, then using a few command-line tools to capture the data. It can seem complex at first, but it follows a logical sequence.

While the video is an excellent practical guide, the official ESP-IDF documentation provides the formal background.

Analyzing the Trace Data

Once you have your trace files (pro.bin and app.bin), you can open them in the SystemView application.

When analyzing your project, you could use this to visually confirm that when a message is sent to the motor task's queue, it immediately preempts the sensor task, just as we designed in the last lesson. You could also identify if any task is running for too long and starving others.

You can even send your own custom messages from your code to the SystemView timeline for debugging, which is demonstrated from 28:59 in the same video (esp_sysview_v_printf). This allows you to mark specific events in your application logic, like "Motor command received" or "Target position reached".

2. Programmatic Health Checks

SystemView is invaluable for deep-dive analysis, but sometimes you just need to check vital signs programmatically. FreeRTOS provides built-in functions to poll the status of your tasks, which you can use to log system health or trigger alerts.

This approach is less intrusive than a full JTAG trace and can be built directly into your production firmware.

Analyzing Memory Usage

Memory corruption is a frequent source of bugs in embedded systems. A common cause is a stack overflow, where a task uses more stack memory than it was allocated, overwriting memory belonging to other tasks or data.

Stack Memory:
Every task has its own stack, used for local variables, function arguments, and return addresses. The uxTaskGetStackHighWaterMark() function is your primary tool for stack analysis. It returns the minimum amount of free stack space (in words) a task has had since it started. A low "high water mark" is a red flag that you are close to a stack overflow.

You could create a simple "monitor" task that periodically checks the stack high water mark of all your critical tasks and prints a warning if any drop below a safe threshold (e.g., a few hundred bytes).

// Example of a monitoring function
void monitor_tasks(void *pvParameters) {
    while (1) {
        // Get stack high water mark for the motor task (assuming you have its handle)
        UBaseType_t motor_stack_hwm = uxTaskGetStackHighWaterMark(motor_task_handle);
        printf("Motor Task Stack HWM: %u words\n", motor_stack_hwm);

        // Check the sensor task
        UBaseType_t sensor_stack_hwm = uxTaskGetStackHighWaterMark(sensor_task_handle);
        printf("Sensor Task Stack HWM: %u words\n", sensor_stack_hwm);
        
        if (motor_stack_hwm < 200) {
            printf("WARNING: Motor task stack is getting low!\n");
        }

        vTaskDelay(pdMS_TO_TICKS(10000)); // Check every 10 seconds
    }
}

Heap Memory:
The heap is the pool of memory used for dynamic allocations (new, malloc). While we won't dive deep into heap analysis tools today, you can get a quick snapshot of available memory using esp_get_free_heap_size(). More advanced tools, like the one shown below, can trace heap usage over time to find memory leaks.

Analyzing CPU Load

To see how much processing time each task is consuming, you can use vTaskGetRunTimeStats(). This function generates a nicely formatted table showing the absolute run time and percentage of total CPU time for each task.

To use it, you first need to enable configGENERATE_RUN_TIME_STATS and related macros in your sdkconfig file (via menuconfig) or FreeRTOSConfig.h. Then, you can call the function like this:

// Buffer to hold the stats table
char stats_buffer[1024];

// Generate and print the stats
vTaskGetRunTimeStats(stats_buffer);
printf("--- Task Runtime Stats ---\n%s\n", stats_buffer);

This is an excellent way to quickly confirm that your system isn't overloaded and to identify any tasks that are consuming more CPU time than expected.

Conclusion

Congratulations on completing this lesson! You've now learned how to move from designing a system based on theory to verifying its real-world performance through measurement and analysis.

Key Takeaways:

• Segger SystemView is a powerful tool for visualizing task execution, preemption, and CPU load, giving you a deep understanding of your system's dynamic behavior.
• SystemView relies on the ESP-IDF Application Tracing library, which sends event data from the ESP32 to your host computer via JTAG and OpenOCD.
• The uxTaskGetStackHighWaterMark() function is essential for monitoring stack usage and preventing dangerous stack overflows.
• The vTaskGetRunTimeStats() function provides a quick, programmatic way to check the CPU load of all tasks in your system.

In our final lesson, we will put everything together. We will use the analysis tools you've just learned about to guide our efforts as we debug and optimize our multi-task application to meet performance requirements, such as response time and stability.