Using an RTOS is an excellent thing: it provides services and allows to scale my application. But it adds complexity. With many tasks, queues and semaphores it is hard to have an overview what is going on. To get visibility, Martin Bucher has developed in a bachelor diploma work the FreeRTOS Trace Probe.
The concept is the following: the application running FreeRTOS is using RTOS hooks. The hooks are part of the FreeRTOS API, but it is up to the application to implement them. The application implements the hooks with a Processor Expert component. That component sends out the trace messages over a communication channel (SCI, I2C, SPI, etc). The Probe Hardware collects the hook messages. The collected trace data is visualized on the host:
The FreeRTOS Trace Probe has following parts:
- Trace Hooks in application: the target application RTOS is using the FreeRTOS Hook API. The target application enables and configures the hooks in the FreeRTOS Trace component:
- Processor Expert Hook Implementation: A Processor Expert component integrated with the FreeRTOS component which implements the trace hooks of the RTOS.
- Probe Hardware: An additional PCB compatible with the Towersystem. It has a battery buffered real-time clock, an SD card socket plus trace pins with level shifter. Using the connectors the hardware connects to the communication channel of the target application (e.g. I2C):
- Trace Probe Firmware: The firmware is running FreeRTOS on an ColdFire MCF52259 and is using Processor Expert components:
- Viewer Software on the Host: a Java application running on the host to visualize the trace information:
The concept worked well. Using a communication channel to stream the data off the target board is used instead of using a RAM buffer. The disadvantage is that the communication channel limits the bandwidth and amount of trace data. But for typical use cases it was good enough, especially if I limit the amount of data.
Happy RTOS Tracing 🙂