The easiest way to stream Tracealyzer traces from an RTOS is often via a SEGGER J-Link debug probe, using the RTT channel. This relies on a RAM buffer that is read by the J-Link probe while the target system is executing. This is usually fast and reliable, but in case you encounter issues, please check [...]
The Tracealyzer recorder for FreeRTOS, SafeRTOS or Micrium µC/OS can be configured to stream the trace data via any interface you might have available. If you have designed your own custom stream port but are having problems getting a reliable transfer or sufficient throughput, there are several things you can try.
To run Tracealyzer 4 on Linux, the first thing you'll need is Tracealyzer version 4.2 or later. Next, you need to install Mono. For most distributions there's a package called "mono-complete", though some distributions and package systems may instead use simply "mono". There may be additional requirements, in particular for Debian/Ubuntu- and Fedora-based systems. See [...]
The improved trace recorder library is the biggest change in Tracealyzer v3.1, at least for FreeRTOS, Micrium and SafeRTOS. We have merged snapshot and streaming support into a single recorder module that support both modes, and improved the API and documentation to make it easier to use. If you are using an older version of the [...]
Software-based tracing always means some processing overhead, where the exact amount is f x e, where f is the average event frequency and e is the average execution time for storing an event. This is very dependent on your application and processor. The more RTOS calls, the larger overhead. The faster processor, the less overhead. Let's put in some [...]
Floating network licenses offer a flexible licensing solution for most development teams. With a floating license, you can install the tool on any number of computers, but the number of concurrent users is limited by the license server. If you need to support more concurrent users, you can extend the license to multiple floating seats. Our [...]
If asserts are enabled the recorder configuration (trcConfig.h), this error is generated in uiTraceGetPriorityProperty when a task has an "object handle" value larger than expected. Our FreeRTOS recorder assignes each task an 8-bit "object handle" (the "id" parameter in uiTraceGetPriorityProperty), which should be in the range [1..NTask]. The NTask constant is defined in trcConfig.h and [...]
Our Tracealyzer versions for microcontroller RTOS uses Percepio's own recorder library, which uses separate definitions for critical sections within the recorder. This since the standard critical sections offered by some RTOS kernels, like portENTER_CRITICAL/portEXIT_CRITICAL in FreeRTOS, might not safe to use from interrupt (kernel) context. Some recorder functions are called both from task-level and interrupt-level [...]
To trace the execution of exception/interrupt handlers (ISRs), you need to call vTraceStoreISRBegin and vTraceStoreISREnd in the beginning and in the end of the handler function. The vTraceStoreISREnd routine normally assumes a return to the previously executing task. But sometimes another ISR is pending and executes in direct sequence, making this assumption incorrect. For instance, ARM Cortex-M devices [...]
If you get this error when compiling the recorder, you are probably using an older version of FreeRTOS (v7.5.x or earlier) together with a newer version of the recorder library. The FreeRTOS variable 'uxPendedTicks' was before v7.5.2 named 'uxMissedTicks', so you need to replace uxPendedTicks with uxMissedTicks in the definition of traceTASK_INCREMENT_TICK in trcKernelPort.h Update: [...]
If you have a node-locked license for a Percepio Tracealyzer software and wish to move it to another computer, please complete Percepio License Migration Request and send a signed copy to support@percepio.com.
Tracealyzer for Linux displays the scheduling priority reported by LTTng. For Linux processed with "normal" dynamic scheduling, this value is typically not meaningful. This is mainly intended for processes with static real-time priorities.
Tracealyzer for VxWorks uses the same data source as System Viewer in Wind River Workbench, but provides a more powerful visualization featuring over 20 different views that all are interconnected in clever ways. Tracealyzer is more intuitive to use and gives a much better understanding of your system. Some unique features of Tracealyzer are: Trace [...]
The Tracealyzer support for FreeRTOS, SafeRTOS and Micrium relies on Percepio's own recorder library. This can be used on most processors and contains ports for several common processor families, including: Arm Cortex-M devices, e.g., STM32, NXP LPC series, Renesas Synergy, etc. Arm Cortex-A9 devices, e.g. Xilinx Zynq. Renesas RX600 series Microchip PIC32 series Atmel AVR32 [...]
(This answer is only applicable for Percepio's own recorder library, used for e.g. FreeRTOS, OpenRTOS, SafeRTOS and Micrium µC/OS) Streaming mode As for v4.1.6, Tracealyzer supports streaming via SEGGER J-Link, IAR I-Jet and Keil ULINKpro/ULINKplus. Streaming is also possible in other ways, e.g. using USB CDC or a network connection. IAR users can find more [...]
(This answer is only applicable for Percepio's own recorder library, used for e.g. FreeRTOS, OpenRTOS, SafeRTOS and Micrium µC/OS) It depends if you are using snapshot or streaming mode. Snapshot mode requires a decent RAM buffer if you want a long trace. A RAM buffer of 5-10 KB can give a trace of 50-200 ms, depending on [...]
(This answer is only applicable for Percepio's own recorder library, used for e.g. FreeRTOS, OpenRTOS, SafeRTOS and Micrium µC/OS) The below table shows an example, using version 2.5.1 of the recorder library when compiled for ARM Cortex M4 (Atmel SAM4S16C) using ARM GCC v4.7.3. Recorder configuration Compiler optimization Flash usage Basic features -Os (minimum size) [...]
(This answer is only applicable for Percepio's own recorder library, used for e.g. FreeRTOS, OpenRTOS, SafeRTOS and Micrium µC/OS) Interrupt handlers (ISRs) are not recorded by default. To record ISRs, you need to add two calls in the interrupt handlers you wish to record, vTraceStoreISRBegin in the very beginning and vTraceStoreISREnd in the very end. [...]
You need to set a name for the ISR using vTraceSetISRProperties, otherwise the numeric ID stored using vTraceStoreISRBegin is displayed.
If you have interrupt handlers using interrupt-level kernel functions, but are not calling vTraceStoreISRBegin and vTraceStoreISREnd, the recorder assumes that the kernel call was made from an interrupt handler, but does not know the identity of the interrupt handler. In this case, the name is set to "ISR using Object", where Object is the queue [...]
Use vTraceSetQueueName, vTraceSetSemaphoreName or vTraceSetMutexName, as in the below example: actuatorQ = xQueueCreate(3, sizeof(QueueMessage) ); if (actuatorQ != NULL) { vTraceSetQueueName(actuatorQ, "ActuatorQueue"); // Set the name ... } else { ... // Error handling }
Our Trace Recorder Library used for FreeRTOS+Trace, SafeRTOS+Trace and Micrium µC/Trace is quite easy to port, as we have made a significant effort to generalize it. All kernel-specific definitions are located in trcKernelPort.c/.h, but you need to insert instrumentation in the kernel and add new fields to the kernel object data types. We welcome new [...]
The name is latin and means "to perceive", i.e., to become aware or conscious of something.