Skip to content
Snippets Groups Projects
Commit 1e4398bc authored by Henrik Tjäder's avatar Henrik Tjäder
Browse files

Merge branch 'master' into 'master'

fixed typos and spelling

See merge request !1
parents 77a2d150 7aa9f040
Branches
No related tags found
No related merge requests found
......@@ -5,11 +5,11 @@ Are We Embedded Yet
## D7018E - Special Studies in Embedded Systems
Disclaimer: This document is in beta state!!!!! Just to give a hint how the course will look like.
The course will be given as a self study course with a set of introductional seminars and accompanying mandatory assignments, followed by a larger assignment (project). The project can be carried out individually or in groups dependent on size. Grading will be individual, based on agreed requirements between the student and the teacher, showing understanding and abilities regarding:
The course will be given as a self study course with a set of introductional seminars and accompanying mandatory assignments, followed by a larger assignment (project). The project can be carried out individually or in groups depending on size. Grading will be individual, based on agreed requirements between the student and the teacher, showing understanding and abilities regarding:
1. The Rust ecosystem. [ecosystem](doc/Ecosystem.md)
Rustup (stable vs nightly), crates and toml files, cargo, rustc, llvm, gdb/lldb (and additional tooling rls, rustfmt, racer, xargo etc.) The Rust core and standard library. Building, bebugging/testing, documenting and publishing Rust applications and libraries.
Rustup (stable vs nightly), crates and toml files, cargo, rustc, llvm, gdb/lldb (and additional tooling rls, rustfmt, racer, xargo etc.) The Rust core and standard library. Building, debugging/testing, documenting and publishing Rust applications and libraries.
2. Simple applications in Rust
......@@ -21,7 +21,7 @@ The course will be given as a self study course with a set of introductional sem
4. The Rust Memory Model
Theoretical underpinning, as well as impact to both memory safatey and code generation. Exterior (inherited) and interior mutability (Cell). Move vs. copy semantics, relation to Clone and Copy traits. Lifetimes and scoping. Static lifetimes, and the relation to the Sync trait.
Theoretical underpinning, as well as an impact on both memory safety and code generation. Exterior (inherited) and interior mutability (Cell). Move vs. copy semantics, relation to Clone and Copy traits. Lifetimes and scoping. Static lifetimes, and the relation to the Sync trait.
6. Memory Safe Concurrency
......@@ -33,7 +33,7 @@ The course will be given as a self study course with a set of introductional sem
8. Building and debugging embedded code in Rust
Hardware abstractions using svd2rust (autogenerated from vendor provided SVD specifications). Compiling using xargo. Setting up openocd and gdb.
Hardware abstractions using svd2rust (autogenerated from vendor-provided SVD specifications). Compiling using xargo. Setting up openocd and gdb.
9. Pre-processing
Custom build.rs build scripts, and the RTFM Concurrent Reactive Component model.
......@@ -41,7 +41,7 @@ The course will be given as a self study course with a set of introductional sem
## Course Format
Please fill out the [doodle](http://doodle.com) so we can arrange for a first scheduled seminar. We will use telegram [telegram](http://telegram.com) in order to confirm the preferred date. On the first seminar we will schedule 10 sessions for covering the above topics.
Please fill out the [doodle](http://doodle.com) so we can arrange for a first scheduled seminar. We will use telegram [telegram](http://telegram.com) in order to confirm the preferred date. On the first seminar, we will schedule 10 sessions for covering the above topics.
Each topic will be accompanied by a set of small illustrative examples and assignments that each student should master (learning goals). On the following session, each student should prepare to discuss and demonstrate their solutions.
......@@ -51,17 +51,17 @@ Each project should be reported in terms of a git Rust crate, with sufficient do
There will be two presentation rounds (at end of LP2 and LP3). Students taking (too many other) courses during LP2 may choose to present their project at end of LP3 (instead of LP2). Presentations will be oral, where the student(s), will present and demonstrate their work.
Projects should be related to embedded programming, either on the target side (some application using the RTFM-core or CRC model), or on the host side, communicating with an embedded target running Rust RTFM. E.g., two groups can work together with building a system, e.g., with back-end processing of data collected by the embedded system, or proividing a front-end to the embedded system. Alternatively, host side project could relate the development of the RTFM-core/ RTFM-CRC frameworks or related tools (e.g. LLWM-KLEE as a backend for analysis of Rust code).
Projects should be related to embedded programming, either on the target side (some application using the RTFM-core or CRC model), or on the host side, communicating with an embedded target running Rust RTFM. E.g., two groups can work together with building a system, e.g., with back-end processing of data collected by the embedded system, or by providing a front-end to the embedded system. Alternatively, host side project could relate the development of the RTFM-core/ RTFM-CRC frameworks or related tools (e.g. LLWM-KLEE as a backend for analysis of Rust code).
## Resources
Students will carry out the assignments on their personal laptops (in case you don't have a working laptop we will try to lend you one). Tools used are available for linux and osx, but with a bit of trickery windows based installations should be possible (but you are on your own here). In case you don't run osx/linux native, virtual box or wmware is possible, though debugging of target MCUs are feasible it is a bit more tricky.
Students will carry out the assignments on their personal laptops (in case you don't have a working laptop we will try to lend you one). Tools used are available for Linux and OSX, but with a bit of trickery windows based installations should be possible (but you are on your own here). In case you don't run OSX/Linux native, virtual box or VMware is possible, though debugging of target MCUs are feasible it is a bit more tricky.
Embedded targets STM32F401RE/411RE (Nucleo-64) will be made available to all students. You will need to get an mini-usb cable yourselves. If you prefer to work with some other ARM Cortex M processor, let us know and we will have a look at available support.
Embedded targets STM32F401RE/411RE (Nucleo-64) will be made available to all students. You will need to get a mini-USB cable yourselves. If you prefer to work with some other ARM Cortex M processor, let us know and we will have a look at available support.
Teaching material will be made available through git (this project), build and refined throughout the course.
We encourage all sorts of collaborations in between the students. Rust is not the easiest language to learn, and we will cover a lot of ground. Use the seminars to try to get as much as possible by being well prepared in order to succeed. We will use telegram as the main means of communictation and support from teachers as well as other fellow students, (this way information will reach everyone, keeping support as efficient as possible).
We encourage all sorts of collaborations in between the students. Rust is not the easiest language to learn, and we will cover a lot of ground. Use the seminars to try to get as much as possible by being well prepared in order to succeed. We will use telegram as the main means of communication and support from teachers as well as other fellow students, (this way information will reach everyone, keeping support as efficient as possible).
# Course in detail
......@@ -82,20 +82,19 @@ Seminars
* [3 - Common Programming Concepts](https://doc.rust-lang.org/book/second-edition/ch03-00-common-programming-concepts.html).
* Assignment 1
Extend the guessing game application such to give an error message on ill formated input, (use the Restult::Err type). Add a counter to the number of tries and write the number of tries for each iteration and on "winning".
Extend the guessing game application such to give an error message on ill-formatted input, (use the Result::Err type). Add a counter to the number of tries and write the number of tries for each iteration and on "winning".
Make a github account (if you don't have it). Make a github project whith your code, along with a README.md for usage instructions.
Make a GitHub account (if you don't have it). Make a GitHub project with your code, along with a README.md for usage instructions.
Prepare to present your development for the next seminar.
2. Basic Programming
* Preparation
Solve and be prepared to present Assignment 1.
* Assessment
We will in class install, test and comment on one of Your solutions. That is, make sure your `crate` on git actually works, and that the accompanying `readme.md` is sufficient for your follow students in order to recreate the result.
We will in the class install, test and comment on one of Your solutions. That is, make sure your `crate` on git actually works, and that the accompanying `readme.md` is sufficient for your fellow students in order to recreate the result.
Later in the course, you will assess each others assignments by creating an `issue` to their development. More on that later.
* Topic
......@@ -139,10 +138,10 @@ Seminars
Finish Assignment 2.
* Topic
In deapth discussion of underlying theory, linear types (relation to functional programming). The *Affine* type system of Rust, requirements on the programmer, and guarantees offered by the compiler. Lifetimes, of stack allocated and global variables. Relation to C++ `unique pointers`.
In-depth discussion of underlying theory, linear types (relation to functional programming). The *Affine* type system of Rust, requirements on the programmer, and guarantees offered by the compiler. Lifetimes, of stack allocated and global variables. Relation to C++ `unique pointers`.
* Assignment
a. Recall the D0013E course lab2/4, where you decrypted an message in assembler (lab2) and C (lab 4). Now, let's re-implement the lab in Rust (base your development on group number [1's](http://www.sm.luth.se/csee/courses/smd/D0013E/labs/lab1underlag/grupp_01.lab1_underlag.s ) lab assignment).
a. Recall the D0013E course lab2/4, where you decrypted a message in assembler (lab2) and C (lab 4). Now, let's re-implement the lab in Rust (base your development on group number [1's](http://www.sm.luth.se/csee/courses/smd/D0013E/labs/lab1underlag/grupp_01.lab1_underlag.s ) lab assignment).
You have to be careful about the signed/unsigned operations and use `wrapping` arithmetics to avoid panics due to unsigned *carry* and signed *overflow*.
......@@ -152,9 +151,9 @@ Seminars
b. Make the `seed`, `abc`,`coded` and `plain` heap allocated. Accessing those will require some `unsafe` code. (Keep the unsafe blocks as local as possible.)
c. Safety analysis. Provoke the implementation, by omitting the `'\0'` (null termintation). Observe the result and motivate the behavior in terms of your understanding of the Rust memory model. Under which circumpstances do you consider 3a and 3b to have same/different memory safety.
c. Safety analysis. Provoke the implementation, by omitting the `'\0'` (null termination). Observe the result and motivate the behavior in terms of your understanding of the Rust memory model. Under which circumstances do you consider 3a and 3b to have same/different memory safety.
Update your git with two new branches (`3a, 3b`), and update docmentation to cover usage and analysis (`3c`).
Update your git with two new branches (`3a, 3b`), and update the documentation to cover usage and analysis (`3c`).
4. Cortex-M, are we embedded yet
* Preparation
......@@ -172,7 +171,7 @@ Seminars
* Building and debugging your first application.
* Assignment
a. Backport assignment `3b` to your choosen target. Use semihosting in order to `write` the resulting string to the host. You may need to use `--release` for decoding the long (`coded`) message, as being deeply recursive unoptimized code may run out of stack memory.
a. Backport assignment `3b` to your chosen target. Use semihosting in order to `write` the resulting string to the host. You may need to use `--release` for decoding the long (`coded`) message, as being deeply recursive unoptimized code may run out of stack memory.
b. Discuss from a memory safety perspective the outcome.
......@@ -213,8 +212,8 @@ Seminars
Implement a simple system with two tasks
* a perodic task executing each 10ms, that blinks the onboard LED, and
* usart task receiving commands (pause, start, period)
* a periodic task executing each 10ms, that blinks the onboard LED, and
* USART task receiving commands (pause, start, period)
* a shared resource (data structure) protecting the command and period
Make a new git with the development and documentation.
......@@ -225,7 +224,7 @@ Seminars
Be prepared to present the progress on assignment 4.
* Topic
We will cover implementation of the RTFM-core crate.
We will cover the implementation of the RTFM-core crate.
Special focus to `macro_rules` and `procedural macros`.
......@@ -254,7 +253,7 @@ Seminars
Discussion of projects
* Assignment
Write a project specicification including individual grading assessment critera.
Write a project specification including individual grading assessment criteria.
10. Wrap-up
* Preparation
......
......@@ -10,44 +10,44 @@ The `rustc` compiler is at heart of the Rust Ecosystem. Other tools of great hel
The Rust ecosystem also provides support to program development, in terms of external `crates` for code completion formatting and formatting
* [racer](https://crates.io/crates/racer/), Code completion for Rustbuild system and package/crate manager
* [rustfmt](https://crates.io/crates/rustfmt), Tool to find and fix Rust formatting issues
* [rls-preview](https://github.com/rust-lang-nursery/rls), Rust Language Server (RLS). RLS is a server that runs in the background, providing IDEs, editors, and other tools with information about Rust programs. The `rls-preview` is in alpha state, meaning that its not guaranteed to compile/work. (You may check under build/passing, the latest changes that passed compilation.)
* [rls-preview](https://github.com/rust-lang-nursery/rls), Rust Language Server (RLS). RLS is a server that runs in the background, providing IDEs, editors, and other tools with information about Rust programs. The `rls-preview` is in alpha state, meaning that it's not guaranteed to compile/work. (You may check under build/passing, the latest changes that passed compilation.)
Rust support for various IDEs and editors
* [rls](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust), Rust support for Visual Studio Code, based on the `rls-preview`. This is the refererence implementation for `rls` support (currently in alpha/preview state).
* [rls](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust), Rust support for Visual Studio Code, based on the `rls-preview`. This is the reference implementation for `rls` support (currently in alpha/preview state).
* [rustdt](http://rustdt.github.io/), Rust support for the Eclipse platform (currently not further maintained)
* Atom, Sublime, Code::Blocks support is also available
Other tools that come in handy for embedded development
* [itm](https://crates.io/crates/itm) Tool to parse and dump ITM packets
* add here your favorite tools supproting Rust development
* add here your favorite tools supporting Rust development
# Installation
We suggest a linux or OSX development environment, though Rust related tools are also available under Windows. Install [rustup](https://www.rustup.rs/), Rust tool-chain manager using the link, and go from there.
We suggest a Linux or OSX development environment, though Rust related tools are also available on Windows. Install [rustup](https://www.rustup.rs/), Rust tool-chain manager using the link, and go from there.
# Rustup
The [rustup](https://www.rustup.rs/), tool manager allows you to manage multiple tool chain installations. Rust is distrubuted in three channels (`stable`, `beta` and `nightly`). You may set the default toolchain:
The [rustup](https://www.rustup.rs/), tool manager allows you to manage multiple tool chain installations. Rust is distributed in three channels (`stable`, `beta` and `nightly`). You may set the default toolchain:
```
rustup default nightly-2017-10-22-x86_64-unknown-linux-gnu
rustup default nightly-2017-10-22-x86_64-unknown-Linux-gnu
```
and get information on the status of `rustup`
```
rustup show
```
Nightly tool chains allow for the development of libraries and applations including `unsafe` code using features not available on the `stable channel` (which will be necessary for the later excercises). For some tools to work (`rls/rustfmt`) you need to install additional components. For this to work, you should use a nightly toolchain for which all tools and components work (currently `nightly-2017-10-30` is the latest). Here is an example:
Nightly tool chains allow for the development of libraries and applications including `unsafe` code using features not available on the `stable channel` (which will be necessary for the later exercises). For some tools to work (`rls/rustfmt`), you need to install additional components. For this to work, you should use a nightly toolchain for which all tools and components work (currently `nightly-2017-10-30` is the latest). Here is an example:
```
rustup default nightly-2017-10-30
rustup component add rls-preview
rustup component add rust-analysis
rustup component add rust-src
```
`rls-preview`, `rust-analysis` and `rust-src` are required for RLS support (including cross referencing to the standard library, code completion and formatting).
`rls-preview`, `rust-analysis` and `rust-src` are required for RLS support (including cross-referencing to the standard library, code completion and formatting).
# Cargo
Cargo is the go-to tool for managing Rust application and your own Rust developments (see [cargo](https://crates.io/) for for detailed documentation).
Cargo is the go-to tool for managing Rust application and your own Rust developments (see [cargo](https://crates.io/) for detailed documentation).
By default your Rust related tools will be stored in `~/.cargo`, this directory should be added to your `$PATH` environment. `cargo` and `rustup` works closely together, e.g., you may tell `cargo` to use a specific toolchain for the build.
......@@ -59,9 +59,9 @@ There is also another (old) crate named `rustfmt`, that can be compiled with the
# Rust Crates
A *crate* is a unit of compilation, being either a *library* or an exectuable *application* (binary). Crates are managed (compiled, installed, removed, updated, etc.) by the [cargo](https://crates.io/) tool.
A *crate* is a unit of compilation, being either a *library* or an executable *application* (binary). Crates are managed (compiled, installed, removed, updated, etc.) by the [cargo](https://crates.io/) tool.
`*.toml` files are used throughtout Rust developments for giving configuration (meta) information (essentially replacing the need of Makefiles). The `Cargo.lock` file shows the cashed dependencies (you may delete the `Cargo.lock` file to force updating dependencies, `cargo clean` may not be enough).
`*.toml` files are used throughout Rust developments for giving configuration (meta) information (essentially replacing the need of Makefiles). The `Cargo.lock` file shows the cashed dependencies (you may delete the `Cargo.lock` file to force updating dependencies, `cargo clean` may not be enough).
Dependencies (may) include a minimal version, following the [semver](http://semver.org/) versioning standard.
......@@ -71,15 +71,15 @@ Dependencies (may) include a minimal version, following the [semver](http://semv
See [rls](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust) for installing the RLS extension.
You will need to pin the specific toolchain version used, by setting the `"rust-client.channel": "nightly-2017-10-30"` in your `vscode` *user* settings (this will be stored in a file `~/.config/Code/User/settings.json` and used for all your `vscode` projects. Settings may be set individually for each *workspace*, overriding the defaults. Regarding the `"rust-client.channel"` setting, a *workspace* setting would force the specific version (overriding the default), and may not work when code is distributed (as other developers may be on other toolchains).
You will need to pin the specific toolchain version used, by setting the `"rust-client.channel": "nightly-2017-10-30"` in your `vscode` *user* settings (this will be stored in a file `~/.config/Code/User/settings.json` and used for all your `vscode` projects. Settings may be set individually for each *workspace*, overriding the defaults. Regarding the `"rust-client.channel"` setting, a *workspace* setting would force the specific version (overriding the default), and may not work when the code is distributed (as other developers may be on other toolchains).
For RLS to work, `vscode` need a path to the `rls-preview` library (using the environment variable `LD_LIBRARY_PATH` (linux), `DYLD_LIBRARY_PATH` (OSX ?)).
For RLS to work, `vscode` need a path to the `rls-preview` library (using the environment variable `LD_LIBRARY_PATH` (Linux), `DYLD_LIBRARY_PATH` (OSX ?)).
```
export LD_LIBRARY_PATH=$(rustc --print sysroot)/lib
```
You may add this to your `~/.bash_profile`, and start vscode (`code` is the name of the executable) in a new terminal (to ensure that the `LD_LIBRARY_PATH` (linux) `DYLD_LIBRARY_PATH` (OSX?) is correctly set). If `code` is run from your window manager (e.g., `plasma`), make sure that the environment is set correctly.
You may add this to your `~/.bash_profile`, and start vscode (`code` is the name of the executable) in a new terminal (to ensure that the `LD_LIBRARY_PATH` (Linux) `DYLD_LIBRARY_PATH` (OSX?) is correctly set). If `code` is run from your window manager (e.g., `plasma`), make sure that the environment is set correctly.
Under the hood: `rustc --print sysroot` gives you the path to the root of the current toolchain. So its important that the toolchain is set correctsy by `rustup` for this to work.
Under the hood: `rustc --print sysroot` gives you the path to the root of the current toolchain. So its important that the toolchain is set correctly by `rustup` for this to work.
## GIT
......@@ -87,4 +87,4 @@ You may choose to use the [gitlens](https://github.com/eamodio/vscode-gitlens) e
## Native Debug
The [Native Debug](https://github.com/WebFreak001/code-debug) extension allows for debugging Rust application from within `vscode`. Native Debug supports both `lldb` (LLVM) and `gdb` (GNU)
debuggers. For embedded development you will use the latter. See Embedded.md (TODO) for further details.
\ No newline at end of file
debuggers. For embedded development, you will use the latter. See Embedded.md (TODO) for further details.
\ No newline at end of file
# Embedded Programming in Rust
# ARM Toolchain
Rust relying on LLVM is already a cross compiler, however currently linking to embedded targets are done using `binutils`. Under arch you can install the complete GNU toolchaion for ARM using the package `arm-none-eabi-gcc`, which also installs `arm-none-eabi-binutils`. (The package also installs `arm-none-eabi-gdb`, which you will use later for debugging.)
Rust relying on LLVM is already a cross-compiler, however currently linking to embedded targets are done using `binutils`. Under arch you can install the complete GNU toolchain for ARM using the package `arm-none-eabi-gcc`, which also installs `arm-none-eabi-binutils`. (The package also installs `arm-none-eabi-gdb`, which you will use later for debugging.)
# Openocd
In order to debug code on the ARM target you need to establish a connection, e.g., using [openocd](http://openocd.org/), available under arch as `openocd`. Later you will start `openocd` in the background using e.g.:
......@@ -17,7 +17,7 @@ In order to debug code on the ARM target you need to establish a connection, e.g
(Assuming that this is a `nucleo stm32f401re` target, programmed using the onboard `stlink-v2-1` interface.)
## port configuration
By default `openocd` listens at port `3333` for incoming gdb connections. If you want to program/dubug multiple targets using SWD (Serial Wire Debug) like offered by the `stlink` based interfaces you need one interface per target. In that case you may run several instances of `openocd` listening in on different ports. To that end the target configuration is defined in the `target/*.cfg`
By default `openocd` listens at port `3333` for incoming gdb connections. If you want to program/debug multiple targets using SWD (Serial Wire Debug) like offered by the `stlink` based interfaces you need one interface per target. In that case you may run several instances of `openocd` listening in on different ports. To that end the target configuration is defined in the `target/*.cfg`
```
......@@ -51,7 +51,7 @@ For compiling embedded targets install the `xargo` crate.
```> cargo install xargo```
(Your top level module should give the crate-wide attribute `#![no_std]` in order to use `core` instead of `std` as the default library.)
(Your top-level module should give the crate-wide attribute `#![no_std]` in order to use `core` instead of `std` as the default library.)
# Using VS Code
......@@ -61,7 +61,7 @@ Install the latest version of Visual Studio Code using your packet manager, unde
## Rust support
Install the `Rust(rls)` plugin (just search for `Rust` in the extensions, chose the plugin and install). Assuming you already have `rustup` and the Rust tools installed the required crates will be installed autematically. The RLS plugin is experimental but already quite useuful. If it fails installing you may check the [RLS git](https://github.com/rust-lang-nursery/rls), for further instructions (actually you can run the plugin from `java script` source.)
Install the `Rust(rls)` plugin (just search for `Rust` in the extensions, chose the plugin and install). Assuming you already have `rustup` and the Rust tools installed the required crates will be installed automatically. The RLS plugin is experimental but already quite useful. If it fails to install you may check the [RLS git](https://github.com/rust-lang-nursery/rls), for further instructions (actually you can run the plugin from `javascript` source.)
## Debugging
......@@ -97,7 +97,7 @@ Install the latest version of Visual Studio Code using your packet manager, unde
It launches `/usr/bin/arm-none-eabi-gdb` and attach the target on port `:3333`, the `:` indicates that the connection to be on the local host). It assumes `openocd` is running and has established a connection to the target.
Similarly a launch confirguration for release (optimised) builds:
Similarly a launch configuration for release (optimised) builds:
```javascript
{
"type": "gdb",
......@@ -127,7 +127,7 @@ An optimized build is generated by
You may set specific settings in the `Cargo.toml` for each build type (`dev` for debug, `release` for release). Notice debugging of optimized code may be difficult as many symbols are *optimised out* and setting breakpoints may not give the desired results. To that end you may choose to use `asm::bkpt()` (defined in the [contex-m](https://github.com/japaric/cortex-m) crate) in the code instead of breakpoints in the debugger.
## Compilation and Linking
The `xargo/cargo` build system will look into your `.cargo/config` for flags. The first example builds for the `m3` architecture while the second for the `m4` with *hard float* code. Notice, to use the *hard floats*, they need to be enabled in the ARM-core (not enabled at reset by default to save power...). You may have several configurations in the `.cargo/config`, and the `[build] = "..."` determintes the default configuration, it may be overridden e.g, by
The `xargo/cargo` build system will look into your `.cargo/config` for flags. The first example builds for the `m3` architecture while the second for the `m4` with *hard float* code. Notice, to use the *hard floats*, they need to be enabled in the ARM-core (not enabled at reset by default to save power...). You may have several configurations in the `.cargo/config`, and the `[build] = "..."` determinates the default configuration, it may be overridden e.g, by
```
> xargo build ... --target thumbv7m-none-eabi
......@@ -163,9 +163,6 @@ target = "thumbv7em-none-eabihf"
## A note on WFI
If your code hits a `WFI` (Wait For Interrupt), the MCU is put into a low power mode, and by default not accepting new debug request. Thus if trying to connect a new `gdb` session, it will fail (or even worse partially work, while not behaving correctly). To remedy this you may try:
* close `openocd` and restart it
* unplug the the debugger (`stlink` probe), and re-plug it, you may need to hold the `reset` at startup to force the debugger and MCU into a correct state
If we want to overcome this problem alltogether, there is a setting in the ARM-core debug unit that allows incoming connections on `WFI` (this feature is disabled by defauld to save power).
* unplug the debugger (`stlink` probe), and re-plug it, you may need to hold the `reset` at startup to force the debugger and MCU into a correct state
If we want to overcome this problem altogether, there is a setting in the ARM-core debug unit that allows incoming connections on `WFI` (this feature is disabled by default to save power).
\ No newline at end of file
......@@ -12,6 +12,6 @@ We will mainly cover the `stm32f401re` and `stm32f411re` as these models.
# ITM
# Add on boards and supporting crates
# Add-on boards and supporting crates
## BLE
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment