Percepio Detect – Evaluation Package

You find the Detect evaluation package at https://percepio.com/downloads/percepio-detect-2024.3.2.zip

The current version (2024.3) is targeting Arm Cortex-M devices with FreeRTOS or bare-metal code.

If using Windows, before extracting the zip file, make sure it is not blocked.
– Right-click on the zip file and select “Properties”.
– On the first page (General), check for an “Unblock” checkbox at the bottom. If so, check it to unblock the file. The checkbox only shows up for blocked files.

If you already extracted the zip-file and missed the unblocking step, use the following PowerShell command to ensure the extracted files are unblocked:

cd <Percepio Detect folder>
Get-ChildItem -Path . -Recurse | Unblock-File

To run the included demo, follow the Percepio Detect Demo Guide in the root folder. It is only 6 pages long, including plenty of screenshots.

The Detect Server runs in Docker and supports Windows and Linux hosts. The Detect Client is available in two separate versions for Windows and Linux. They include Tracealyzer, the core dump viewer and everything else needed, pre-configured for use with Percepio Detect.

Note that you need a license key for the Detect Server. This is provided by Percepio on request. This should be added in the server start script (in the percepio-server directory). You will also need a separate license key for Tracealyzer.

If using Linux

The Linux client runs in Docker and exports the GUI windows to the host display. As of the 2024.3 release, this works well for Ubuntu 22 but not yet for Ubuntu 24. Also, in the 2024.3 release we missed to update the demo data paths in the client start script (percepio-client.sh), so you need to update the path settings as shown below:
– DEFAULT_ALERTS_DIR=”$(pwd)/../test-data/alert-files”
– DEFAULT_ELF_DIR=”$(pwd)/../test-data”
– DEFAULT_ELF_REL_PATH=”image-stopwatchdemo-stm32l4.elf”
– DEFAULT_SRC_DIR=”$(pwd)/../device-integration/demo-projects/demo-stopwatch-stm32l4″

We are working on an updated Linux client and aim to have that available soon.

Documentation, guides, examples

To integrate Detect with your own system, the entrypoint for the documentation is readme.txt in the root of the zip file. This has references to individual readme files for each part (server, client, receiver).

You find guides, code examples and the target libraries in the device-integration folder, including two pdf files. The main guide for device integration is “Percepio Detect – Device Integration Guide – 2024.3.pdf”. The other guide explains how to use Tracealyzer with the “bare-metal” option, an RTOS-agnostic variant for bare-metal and unsupported RTOSes.

A demo project is included for the STM32 development board B-L475E-IoT01A.

Optimizing RAM usage

You can reduce the RAM usage of the solution using the following settings:

DFM_CFG_MAX_PAYLOAD_CHUNK_SIZE in DFM/config/dfmConfig.h: If the payload is larger than the buffer size, it is divided into multiple smaller chunks that are sent one by one. Default is 2000 bytes.
DFM_CFG_STACKDUMP_SIZE in DFM/config/dfmCrashCatcherConfig.h: How much of the current stack to include in core dumps. This affects the size of an internal buffer for this data. Default is 300 bytes.
TRC_CFG_STREAM_PORT_BUFFER_SIZE in TraceRecorder/streamports/RingBuffer/config/trcStreamPortConfig.h: The size of the TraceRecorder event buffer. Default is 5000 bytes. This decides how long trace history that is provided with the alerts.
TRC_CFG_ENTRY_SLOTS in TraceRecorder/config/trcStreamingConfig.h: The number of object entries allowed in the TraceRecorder symbol table. This is used to store names of tasks, traced ISRs, user event channels etc.
TRC_CFG_ENTRY_SYMBOL_MAX_LENGTH, also in TraceRecorder/config/trcStreamingConfig.h: The number of bytes used to store an object name in the symbol table. If longer names would be used, they are truncated.

Roadmap

In the current version you can catch hard faults, failed asserts, stack corruptions, timing anomalies using “stopwatches” and and also add your own custom alerts on any condition of relevance. Currently we are focusing on taking in feedback from early access users to ensure good support for typical use-cases and setups. During 2025 we aim to provide broader support for automated anomaly detection, like memory usage alerts and CPU load alerts, as well as broader support for other data transfer methods, e.g. via Ethernet or Wi-Fi.