STM32F3Discovery RTIC Jitter Data Logging

Overview

This project demonstrates RTIC task jitter measurement using Rust on the STM32F3Discovery board. The firmware toggles an onboard LED from an RTIC async task, waits for a fixed 100 ms interval using Mono::delay(100.millis()).await, and uses the ARM Cortex-M DWT cycle counter to measure the number of CPU cycles between task resumptions.

The system clock is configured to 72 MHz. Therefore, an ideal 100 ms interval corresponds to:

72,000,000 cycles/second × 0.1 second = 7,200,000 cycles

The program records 1005 timing measurements, skips the first two startup samples, subtracts 7_200_000 cycles from each selected measurement, and outputs 1000 jitter data values through RTT. The RTT output can be redirected on the PC into an external CSV/text file.

This project is supported by multiple embedded Rust toolchains:

OpenOCD + GDB
cargo-embed + GDB
probe-rs + VS Code

Features

Uses RTIC with an async fn task.
Toggles onboard LED PE8 on the STM32F3Discovery board.
Uses rtic-monotonics with the SysTick backend.
Uses the ARM Cortex-M DWT cycle counter for cycle-level timing.
Measures task interval timing for a 100 ms RTIC delay.
Samples 1005 timing values.
Skips the first 2 samples because startup timing may not be accurate.
Outputs exactly 1000 adjusted jitter values through RTT.
Stops future RTT output after the 1000-sample log is printed.
Allows the RTT log to be exported to an external PC file such as jitter_log.csv.

Hardware Requirements

STM32F3Discovery board
STM32F303VCT6 microcontroller
Built-in ST-LINK debugger
USB cable connected to the ST-LINK/debug USB port
PC running VS Code, probe-rs, or another supported toolchain

Software Requirements

Rust toolchain with the embedded target:

rustup target add thumbv7em-none-eabihf

probe-rs tools:

cargo install probe-rs-tools --locked

OpenOCD + GDB, if using the OpenOCD workflow
cargo-embed + GDB, if using the cargo-embed workflow
VS Code with the probe-rs debugger extension, if using the VS Code workflow
arm-none-eabi-gcc and arm-none-eabi-gdb, if using GDB-based workflows

Main Dependencies

The project uses embedded Rust crates such as:

stm32f3xx-hal
rtic
rtic-monotonics
cortex-m
rtt-target
panic-halt or panic-rtt-target, depending on the selected panic/logging setup

Clock Configuration

The firmware configures the STM32F303 clock tree as follows:

Parameter	Value
HSE	8 MHz
SYSCLK	72 MHz
APB1	36 MHz
SysTick monotonic source	`clocks.sysclk().0`
Expected 100 ms count	7,200,000 cycles

The DWT cycle counter is enabled during initialization:

fn enable_dwt_cycle_counter(mut dcb: DCB, mut dwt: DWT) {
    dcb.enable_trace();
    dwt.enable_cycle_counter();
}

Jitter Measurement Method

Inside the RTIC blink task, the firmware records the DWT cycle counter before and after the 100 ms delay:

*cx.local.start = DWT::get_cycle_count();

Mono::delay(100.millis()).await;

*cx.local.end = DWT::get_cycle_count();

The measured task interval is computed as:

cx.local.end.wrapping_sub(*cx.local.start)

The program stores 1005 measured intervals in the local jitter buffer:

jitter: [u32; 1005]

After collecting 1005 measurements, the program skips the first two startup samples and outputs 1000 adjusted jitter values:

for i in 0..1000 {
    rprintln!("{},{}", i, cx.local.jitter[i + 2] - EXPECTED_100MS_CYCLES);
}

The constant is:

const EXPECTED_100MS_CYCLES: u32 = 7_200_000;

Therefore, each reported value is:

reported_jitter = measured_interval_cycles - 7,200,000

The first two samples are ignored because the system may still be stabilizing after startup, and those timing values may not represent steady-state RTIC task timing.

RTT Output Format

The RTT output has a simple CSV-style format:

index,jitter_cycles 1000
0,<jitter_value_0>
1,<jitter_value_1>
2,<jitter_value_2>
...
999,<jitter_value_999>
end_of_log

After end_of_log is printed, the firmware sets rtt_done = true, so no additional RTT jitter data is printed.

Repository Structure

stm32f3_rtic_jitter/
├── .cargo/
│   └── config.toml       # Cargo runner configuration
├── .vscode/
│   ├── launch.json       # VS Code probe-rs debug configuration
│   └── tasks.json        # VS Code cargo build task
├── src/
│   └── main.rs           # RTIC jitter measurement firmware
├── .probe-rs.yaml        # probe-rs chip/debug configuration
├── Cargo.toml            # Rust project manifest
├── Embed.toml            # cargo-embed configuration file
├── openocd.gdb           # GDB load script for OpenOCD workflow
├── embed.gdb             # GDB load script for cargo-embed workflow
└── README.md             # Project documentation

Build the Project

From the project folder, run:

cargo build

For a release build:

cargo build --release

Export 1000 RTT Jitter Values to a PC File

The recommended command for this project is:

probe-rs run --chip STM32F303VCTx target/thumbv7em-none-eabihf/debug/YOUR_PROJECT_NAME > jitter_log.csv

Replace YOUR_PROJECT_NAME with the binary name generated by your Cargo.toml.

For example, if the project binary is named rticjitter, use:

probe-rs run --chip STM32F303VCTx target/thumbv7em-none-eabihf/debug/rticjitter > jitter_log.csv

This command does the following:

Starts the firmware through probe-rs.
Captures RTT output from the STM32F3Discovery board.
Redirects the RTT text output to the PC file jitter_log.csv.
Saves the 1000 adjusted jitter samples in CSV-style format.

After the file contains end_of_log, stop the terminal process with:

Ctrl + C

VS Code Workflow

Open the project folder in VS Code.
Open a terminal using:

Terminal → New Terminal

or press:

Ctrl + `

Build the project:

cargo build

Run the firmware and export RTT output:

probe-rs run --chip STM32F303VCTx target/thumbv7em-none-eabihf/debug/YOUR_PROJECT_NAME > jitter_log.csv

Open jitter_log.csv in VS Code to view the captured jitter data.

Toolchain 1: OpenOCD + GDB

Start OpenOCD

c:\Openocd\openocd -f interface/stlink.cfg -f target/stm32f3x.cfg

Configure `.cargo/config.toml`

Uncomment the OpenOCD runner and comment out other runners:

runner = "arm-none-eabi-gdb -q -x openocd.gdb"

Run from the Project Folder

cargo run

Note: OpenOCD does not automatically flash the MCU unless the GDB script includes the load command.

Toolchain 2: cargo-embed + GDB

Start cargo-embed

cargo embed

Configure `.cargo/config.toml`

Uncomment the cargo-embed runner and comment out other runners:

runner = "arm-none-eabi-gdb -q -x embed.gdb"

Run from the Project Folder

cargo run

Note: cargo-embed can flash and run the program code.

Toolchain 3: probe-rs + VS Code

Start VS Code.
Install the Debugger for probe-rs extension if it is not already installed.
Open the project folder.
Open src/main.rs.
Run or debug the firmware using the VS Code launch configuration, or press F5.

The .vscode/launch.json and .vscode/tasks.json files can be used to build with Cargo and run the firmware through probe-rs.

For RTT data export, use the terminal redirection command instead of only pressing F5:

probe-rs run --chip STM32F303VCTx target/thumbv7em-none-eabihf/debug/YOUR_PROJECT_NAME > jitter_log.csv

Notes on the Measurement

The measured interval includes the RTIC async delay behavior, task resumption timing, and small overhead from the LED GPIO toggle path.
The first two samples are skipped to avoid startup effects.
The output data are cycle counts relative to the ideal 100 ms interval at 72 MHz.
Because the adjusted value is computed by subtracting 7_200_000, the log represents the deviation from the expected 100 ms period.
RTT printing occurs only after all samples are collected, which reduces measurement disturbance during data collection.

Useful Links

License

This project is intended for educational and demonstration purposes. Refer to the repository for licensing details.

wang32/stm32f3_rticjitter

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Languages