Compare revisions

# Some notes on Debugging usin Cortex Debug

In the `launch.json` three profiles are added.

- `Cortex Debug`, running a debug build.

- `Cortex Release`, running a release (optimized) build.

- `Cortex Nightly`, running a release build with inlined assembly (optimized).

All profiles apply to the currently active editor. (So if you e.g., try to debug this file you will get an error.) 

## Short cuts

- Shift-Control-D, to get the list of launch profiles and select the one to use,

- F5, to run the last one selected, or

- F5, continue if already started,

- Shift-F5, to abort debug session,

- F10, to step over funciton (run function till it returns),

- F11, to step into function,

- Shift-F11, to step out of function (run function till it returns),

- Ctrl-Shift-Y, focus debug console.

In the console you can give `gdb` commands directly. Error handling and "tabbing" is sub-par compared to the terminal gdb, but at least it allows you to give `gdb` commands.

It implements a history over sessions, which is neat. (Arrow up/down).

## Console

Examples of useful `gdb` console commands:

> disassemble

> continue

> break *0x8000242

> x 0xe0001004

## Peripherals

The profiles link to `STM32F401.svd`. This file is patched with to include the `DWT` unit where you find the `CYCCNT` register. You can `Right-Click` on the register to choose display format.

This can be used in the lab to observe the content of `CYCCNT` (instead of `x 0xe0001004` in the console).

{

	// See https://go.microsoft.com/fwlink/?LinkId=827846 to learn about workspace recommendations.

	// Extension identifier format: ${publisher}.${name}. Example: vscode.csharp

	// List of extensions which should be recommended for users of this workspace.

	"recommendations": [

		"rust-lang.rust",

		"matklad.rust-analyzer",

		"marus25.cortex-debug",

	],

	// List of extensions recommended by VS Code that should not be recommended for users of this workspace.

	"unwantedRecommendations": [

	]

	"unwantedRecommendations": []

}

 No newline at end of file

     * https://marketplace.visualstudio.com/items?itemName=rust-lang.rust

     * https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug

     */

    // Use IntelliSense to learn about possible attributes.

    // Hover to view descriptions of existing attributes.

    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387

    "version": "0.2.0",

    "configurations": [

        {

            "type": "cortex-debug",

            "request": "launch",

            "name": "Debug (QEMU)",

            "servertype": "qemu",

            "name": "Cortex Debug",

            "servertype": "openocd",

            "cwd": "${workspaceRoot}",

            "preLaunchTask": "Cargo Build (debug)",

            "preLaunchTask": "cargo build --examples",

            "runToMain": true,

            "executable": "./target/thumbv7m-none-eabi/debug/app",

            /* Run `cargo build --example hello` and uncomment this line to run semi-hosting example */

            //"executable": "./target/thumbv7m-none-eabi/debug/examples/hello",

            "cpu": "cortex-m3",

            "machine": "lm3s6965evb",

            "svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",

            "configFiles": [

                "interface/stlink-v2-1.cfg",

                "target/stm32f4x.cfg"

            ],

            "executable": "./target/thumbv7em-none-eabi/debug/examples/${fileBasenameNoExtension}",

            "cpu": "cortex-m4",

        },

        {

            /* Configuration for the STM32F303 Discovery board */

            "type": "cortex-debug",

            "request": "launch",

            "name": "Debug (OpenOCD)",

            "name": "Cortex Release",

            "servertype": "openocd",

            "cwd": "${workspaceRoot}",

            "preLaunchTask": "Cargo Build (debug)",

            "preLaunchTask": "cargo build --examples --release",

            "runToMain": true,

            "executable": "./target/thumbv7em-none-eabihf/debug/app",

            /* Run `cargo build --example itm` and uncomment this line to run itm example */

            // "executable": "./target/thumbv7em-none-eabihf/debug/examples/itm",

            "device": "STM32F303VCT6",

            "svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",

            "configFiles": [

                "interface/stlink-v2-1.cfg",

                "target/stm32f3x.cfg"

                "target/stm32f4x.cfg"

            ],

            "svdFile": "${workspaceRoot}/.vscode/STM32F303.svd",

            "swoConfig": {

                "enabled": true,

                "cpuFrequency": 8000000,

                "swoFrequency": 2000000,

                "source": "probe",

                "decoders": [

                    { "type": "console", "label": "ITM", "port": 0 }

                ]

            }

        }

            "executable": "./target/thumbv7em-none-eabi/release/examples/${fileBasenameNoExtension}",

            "cpu": "cortex-m4",

        },

        {

            "type": "cortex-debug",

            "request": "launch",

            "name": "Cortex Nightly",

            "servertype": "openocd",

            "cwd": "${workspaceRoot}",

            "preLaunchTask": "cargo build --examples --release --nightly",

            // "runToMain": true,

            "svdFile": "${workspaceRoot}/.vscode/STM32F401.svd",

            "configFiles": [

                "interface/stlink-v2-1.cfg",

                "target/stm32f4x.cfg"

            ],

            "executable": "./target/thumbv7em-none-eabi/release/examples/${fileBasenameNoExtension}",

            "cpu": "cortex-m4",

        },

    ]

}

 No newline at end of file

    "version": "2.0.0",

    "tasks": [

        {

            /*

             * This is the default cargo build task,

             * but we need to provide a label for it,

             * so we can invoke it from the debug launcher.

             */

            "label": "Cargo Build (debug)",

            "type": "process",

            "command": "cargo",

            "args": ["build"],

            "type": "cargo",

            "command": "build --example ${fileBasenameNoExtension}",

            "problemMatcher": [

                "$rustc"

            ],

            "group": {

                "kind": "build",

                "isDefault": true

            }

        },

        {

            "label": "Cargo Build (release)",

            "type": "process",

            "command": "cargo",

            "args": ["build", "--release"],

            "problemMatcher": [

                "$rustc"

            ],

            "group": "build"

            "group": "build",

            "label": "cargo build --examples"

        },

        {

            "label": "Cargo Build Examples (debug)",

            "type": "process",

            "command": "cargo",

            "args": ["build","--examples"],

            "type": "cargo",

            "command": "build --example ${fileBasenameNoExtension} --release",

            "problemMatcher": [

                "$rustc"

            ],

            "group": "build"

            "group": "build",

            "label": "cargo build --examples --release"

        },

        {

            "label": "Cargo Build Examples (release)",

            "type": "process",

            "command": "cargo",

            "args": ["build","--examples", "--release"],

            "type": "cargo",

            "command": "build --example ${fileBasenameNoExtension} --release --features nightly",

            "problemMatcher": [

                "$rustc"

            ],

            "group": "build"

        },

        {

            "label": "Cargo Clean",

            "type": "process",

            "command": "cargo",

            "args": ["clean"],

            "problemMatcher": [],

            "group": "build"

        },

            "group": "build",

            "label": "cargo build --examples --release --nightly"

        }

    ]

}

 No newline at end of file

# tracing

cortex-m-semihosting = "0.3.5"

rtt-target = { version = "0.2.2", features = ["cortex-m"] }

rtt-target = { version = "0.3.0", features = ["cortex-m"] }

# panic handlers

panic-halt = "0.2.0"

panic-semihosting = "0.5.4"

panic-rtt-target = { version = "0.1.1", features = ["cortex-m"] }

# panic-semihosting = "0.5.6"

# panic-rtt-target = { version = "0.1.1", features = ["cortex-m"] }

[dependencies.stm32f4]

version = "0.12.1"

We assume Rust to be installed using [rustup](https://www.rust-lang.org/tools/install).

Additionally you need to install the `thumbv7em-none-eabi` target.

```shell

> rustup target add thumbv7em-none-eabi 

```

You may use any editor of choice. `vscode` supports Rust using the  `rust-analyzer` plugin.

---

## Exercises

- `src/main.rs`

  Developing embedded applications in Rust is made simle by the RTIC framework. In this exercise you will familiarize yourself with the basics `init` and `idle`, and see how you can trace the output to a terminal using `cargo-run`.

  You will also learn about `panic`s and how they can be traced.

- `examples/rtt_timing.rs`

  Here you will learn about cycle accurate timing measurements:

  - Using instrumentation code (which introduces bloat and overhead).

  - Non intrusive measurements using the on-chip debug unit and `gdb`.

  - Code generation optimization.

  - Code inspection, `objdump`, debugging and interactive `disassemble`.

  - Code trimming, RTIC is "A Zero-Cost Abstraction for Memory Safe Concurrency".

- `examples/timing_task.rs`

  Here you learn about the Nested Vector Interrupt Controller (NVIC):

  - Tasks are bound to interrupt vectors.

  - Tasks can be pended either by code or by the environment (e.g. on arrival of serial data).

  - The `bkpt` can be inserted in the code to trigger a breakpoint (useful to timing measurements).

  - RTIC has zero-cost task dispatch overhead (well 2-clock cycles but will be fixed to zero).

- `examples/timing_resource.rs`

  Here you will learn about resource handling in RTIC:

  - Implementation of critical sections through priority masking (NVIC-BASEPRI).

  - Direct access to non-preemptable resources.

  - Comparison to threaded counterpart.

//! examples/rtt_simple.rs

#![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use panic_rtt_target as _;

use rtt_target::{rprintln, rtt_init_print};

use stm32f4;

#[rtic::app(device = stm32f4)]

const APP: () = {

    #[init]

    fn init(_cx: init::Context) {

        rtt_init_print!();

        rprintln!("init");

    }

    #[idle]

    fn idle(_cx: idle::Context) -> ! {

        rprintln!("idle");

        loop {

            continue;

        }

    }

};

// > cargo run rtt_simple

//    Compiling app v0.1.0 (/home/pln/courses/e7020e/app)

// Finished dev [unoptimized + debuginfo] target(s) in 0.15s

// Running `probe-run --chip STM32F411RETx target/thumbv7em-none-eabi/debug/examples/rtt_simple`

// flashing program ..

// DONE

// resetting device

// init

// idle

//

// > [Ctrl-C]

// stack backtrace:

// 0: 0x0800031a - rtt_simple::idle

// 1: 0x0800036c - main

// 2: 0x080001da - Reset

//

// [Your answer here]

//

// A.3) Why do we need a wrapping subtraction?

//

// [Your answer here]

//

// ------------------------------------------------------------------------

// Now try a release (optimized build, see `Cargo.toml` for build options).

// B.1) What is the cycle count for the loop?

//

// Now try a release (optimized build, see `Cargo.toml` for build options).

// C.1) What is the cycle count for the loop?

// > cargo run --example rtt_timing --release

// > cargo run --example rtt_timing --release --features nightly

//

// [Your answer here]

//

// ------------------------------------------------------------------------

// D) Now lets have a closer look at the generated assembly.

//

// > cargo objdump --example rtt_timing --release  --features nightly -- --disassemble > rtt_timing.objdump

// > cargo objdump --example rtt_timing --release  --features nightly -- --disassemble --no-show-raw-insn > rtt_timing.objdump

//

// Open the file in you editor and search for the `timed_loop`.

//

//! examples/timing_exam.rs

// #![deny(unsafe_code)]

// #![deny(warnings)]

#![no_main]

#![no_std]

use cortex_m::{asm, peripheral::DWT};

use panic_halt as _;

use rtic::cyccnt::{Duration, Instant, U32Ext};

use stm32f4::stm32f411;

#[no_mangle]

static mut T1_MAX_RP: u32 = 0;

#[no_mangle]

static mut T2_MAX_RP: u32 = 0;

#[no_mangle]

static mut T3_MAX_RP: u32 = 0;

#[rtic::app(device = stm32f411, monotonic = rtic::cyccnt::CYCCNT)]

const APP: () = {

    struct Resources {

        #[init(0)]

        R1: u64, // non atomic data

        #[init(0)]

        R2: u64, // non atomic data

    }

    #[init(schedule = [t1, t2, t3])]

    fn init(mut cx: init::Context) {

        // Initialize (enable) the monotonic timer (CYCCNT)

        cx.core.DCB.enable_trace();

        cx.core.DWT.enable_cycle_counter();

        cx.schedule.t1(cx.start + 100_000.cycles()).unwrap();

        cx.schedule.t2(cx.start + 200_000.cycles()).unwrap();

        cx.schedule.t3(cx.start + 50_000.cycles()).unwrap();

    }

    // Deadline 100, Inter-arrival 100

    #[inline(never)]

    #[task(schedule = [t1], priority = 1)]

    fn t1(cx: t1::Context) {

        asm::bkpt();

        cx.schedule.t1(cx.scheduled + 100_000.cycles()).unwrap();

        asm::bkpt();

        // emulates timing behavior of t1

        cortex_m::asm::delay(10_000);

        asm::bkpt();

        // 2) your code here to update T1_MAX_RP and

        // break if deadline missed

    }

    // Deadline 200, Inter-arrival 200

    #[inline(never)]

    #[task(schedule = [t2], resources = [R1, R2], priority = 2)]

    fn t2(cx: t2::Context) {

        asm::bkpt();

        cx.schedule.t2(cx.scheduled + 200_000.cycles()).unwrap();

        asm::bkpt();

        // 1) your code here to emulate timing behavior of t2

        asm::bkpt();

        // 2) your code here to update T2_MAX_RP and

        // break if deadline missed

    }

    // Deadline 50, Inter-arrival 50

    #[inline(never)]

    #[task(schedule = [t3], resources = [R2], priority = 3)]

    fn t3(cx: t3::Context) {

        asm::bkpt();

        cx.schedule.t3(cx.scheduled + 50_000.cycles()).unwrap();

        asm::bkpt();

        // 1) your code here to emulate timing behavior of t3

        asm::bkpt();

        // 2) your code here to update T3_MAX_RP and

        // break if deadline missed

    }

    // RTIC requires that unused interrupts are declared in an extern block when

    // using software tasks; these free interrupts will be used to dispatch the

    // software tasks.

    extern "C" {

        fn EXTI0();

        fn EXTI1();

        fn EXTI2();

    }

};

// !!!! NOTICE !!!!

//

// Use either vscode with the `Cortex Nightly` launch profile,

// or compile with the feature `--features nightly` in order to

// get inlined assembly!

//

// 1) For this assignment you should first generate a task set that

// matches the example task set from `klee_tutorial/srp_analysis/main.rs`.

//

// Assume that each time unit amounts to 1_000 clock cycles, then

// the execution time of `t1` should be 10_000 clock cycles.

//

// So, instead of measuring execution time of an existing application,

// you are to create a task set according to given timing properties.

//

// Do this naively, by just calling `asm::delay(x)`, where x

// amounts to the number of clock cycles to spend.

//

// Commit your repository once your task set is implemented.

//

// 2) Code instrumentation:

// Now its time to see if your scheduling analysis is accurate

// in comparison to a real running system.

//

// First explain in your own words how the `Instant` is

// used to generate a periodic task instance arrivals.

//

// `cx.schedule.t1(cx.scheduled + 100_000.cycles()).unwrap();`

//

// [Your answer here]

//

// Explain in your own words the difference between:

//

// `cx.schedule.t1(Instant::now() + 100_000.cycles()).unwrap();`

// and

// `cx.schedule.t1(cx.scheduled + 100_000.cycles()).unwrap();`

//

// [Your answer here]

//

// Explain in your own words why we use the latter

// in order to generate a periodic task.

//

// [Your answer here]

//

// Hint, look at https://rtic.rs/0.5/book/en/by-example/timer-queue.html

//

// Once you understand how `Instant` is used, document your crate:

// > cargo doc --open

//

// Once you have the documentation open, search for `Instant`

// Hint, you can search docs by pressing S.

//

// Now figure out how to calculate the actual response time.

// If the new response time is larger than the stored response time

// then update it (`T1_MAX_RP`, `T2_MAX_RP`, `T3_MAX_RP` respectively).

// If the response time is larger than the deadline, you should

// hit a `asm::bkpt()`, to indicate that an error occurred.

//

// You will need `unsafe` code to access the global variables.

//

// Explain why this is needed (there is a good reason for it).

//

// [Your answer here]

//

// Implement this functionality for all tasks.

//

// Commit your repository once you are done with the instrumentation.

//

// 3) Code Testing:

//

// Once the instrumentation code is in place, its finally time

// to test/probe/validate the system.

//

// Make sure that all tasks is initially scheduled from `init`.

//

// You can put WATCHES in vscode for the symbols

// WATCH

//  `T1_MAX_RP`

//  `T2_MAX_RP`

//  `T3_MAX_RP`

// To see them being updated during the test.

//

// The first breakpoint hit should be:

// fn t3(cx: t3::Context) {

//      asm::bkpt();

//

// Check the value of the CYCCNT register.

// (In vscode look under CORTEX PERIPHERALS > DWT > CYCCNT)

//

// Your values may differ slightly but should be in the same

// territory (if not, check your task implementation(s).)

//

// Task Entry Times, Task Nr, Response time Update

//   50240           t3       -

//                            30362

//  100295           t3

//                            30426

//

//  130595           t1

//

// At this point we can ask ourselves a number of

// interesting questions. Try answering in your own words.

//

// 3A) Why is there an offset 50240 (instead of 50000)?

//

// [Your answer here]

//

// 3B) Why is the calculated response time larger than the

// delays you inserted to simulate workload?

//

// [Your answer here]

//

// 3C) Why is the second arrival of `t3` further delayed?

//

// [Your answer here]

// Hint, think about what happens at time 100_000, what tasks

// are set to `arrive` at that point compared to time 50_000.

//

// 3D) What is the scheduled time for task `t1` (130595 is the

// measured time according to CYCYCNT).

//

// [Your answer here]

//

// Why is the measured value much higher than the scheduled time?

//

// [Your answer here]

//

// Now you can continue until you get a first update of `T1_MAX_RP`.

//

// What is the first update of `T1_MAX_RP`?

//

// [Your answer here]

//

// Explain the obtained value in terms of:

// Execution time, blocking and preemptions

// (that occurred for this task instance).

//

// [Your answer here]

//

// Now continue until you get a first timing measurement for `T2_MAX_RP`.

//

// What is the first update of `T2_MAX_RP`?

//

// [Your answer here]

//

// Now continue until you get a second timing measurement for `T1_MAX_RP`.

//

// What is the second update of `T3_MAX_RP`?

//

// [Your answer here]

//

// Now you should have ended up in a deadline miss right!!!!

//

// Why did this happen?

//

// [Your answer here]

//

// Compare that to the result obtained from your analysis tool.

//

// Do they differ, if so why?

//

// [Your answer here]

//

// Commit your repository once you completed this part.

//

// 4) Delay tuning.

//

// So there were some discrepancy between the timing properties

// introduced by the `delay::asm` and the real measurements.

//

// Adjust delays to compensate for the OH to make it fit to

// to the theoretical task set.

//

// In order to do so test each task individually, schedule ony one

// task from `init` at a time.

//

// You may need to insert additional breakpoints to tune the timing.

//

// Once you are convinced that each task now adheres to

// the timing specification you can re-run part 3.

//

// If some task still misses its deadline go back and adjust

// the timing until it just passes.

//

// Commit your tuned task set.

//

// 5) Final remarks and learning outcomes.

//

// This exercise is of course a bit contrived, in the normal case

// you would start out with a real task set and then pass it

// onto analysis.

//

// Essay question:

//

// Reflect in your own words on:

//

// - RTIC and scheduling overhead

// - Coupling in between theoretical model and measurements

// - How would an ideal tool for static analysis of RTIC models look like.

//

// [Your ideas and reflections here]

//

// Commit your thoughts, we will discuss further when we meet.

//! examples/timing_resources.rs

// #![deny(unsafe_code)]

#![deny(warnings)]

#![no_main]

#![no_std]

use cortex_m::{asm, peripheral::DWT};

use panic_halt as _;

use stm32f4::stm32f411;

#[rtic::app(device = stm32f411)]

const APP: () = {

    struct Resources {

        dwt: DWT,

        #[init(0)]

        shared: u64, // non atomic data

    }

    #[init]

    fn init(mut cx: init::Context) -> init::LateResources {

        // Initialize (enable) the monotonic timer (CYCCNT)

        cx.core.DCB.enable_trace();

        cx.core.DWT.enable_cycle_counter();

        rtic::pend(stm32f411::Interrupt::EXTI1);

        init::LateResources { dwt: cx.core.DWT }

    }

    #[task(binds = EXTI0, resources = [shared], priority = 2)]

    fn exti0(cx: exti0::Context) {

        asm::bkpt();

        *cx.resources.shared += 1;

    }