Git Product home page Git Product logo

cortex-m-quickstart's Introduction

cortex-m-quickstart

A template for building applications for ARM Cortex-M microcontrollers

This project is developed and maintained by the Cortex-M team.

Dependencies

To build embedded programs using this template you'll need:

  • Rust 1.31, 1.30-beta, nightly-2018-09-13 or a newer toolchain. e.g. rustup default beta

  • The cargo generate subcommand. Installation instructions.

  • rust-std components (pre-compiled core crate) for the ARM Cortex-M targets. Run:

$ rustup target add thumbv6m-none-eabi thumbv7m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf

Using this template

NOTE: This is the very short version that only covers building programs. For the long version, which additionally covers flashing, running and debugging programs, check the embedded Rust book.

  1. Before we begin you need to identify some characteristics of the target device as these will be used to configure the project:
  • The ARM core. e.g. Cortex-M3.

  • Does the ARM core include an FPU? Cortex-M4F and Cortex-M7F cores do.

  • How much Flash memory and RAM does the target device has? e.g. 256 KiB of Flash and 32 KiB of RAM.

  • Where are Flash memory and RAM mapped in the address space? e.g. RAM is commonly located at address 0x2000_0000.

You can find this information in the data sheet or the reference manual of your device.

In this example we'll be using the STM32F3DISCOVERY. This board contains an STM32F303VCT6 microcontroller. This microcontroller has:

  • A Cortex-M4F core that includes a single precision FPU

  • 256 KiB of Flash located at address 0x0800_0000.

  • 40 KiB of RAM located at address 0x2000_0000. (There's another RAM region but for simplicity we'll ignore it).

  1. Instantiate the template.
$ cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart
 Project Name: app
 Creating project called `app`...
 Done! New project created /tmp/app

$ cd app
  1. Set a default compilation target. There are four options as mentioned at the bottom of .cargo/config. For the STM32F303VCT6, which has a Cortex-M4F core, we'll pick the thumbv7em-none-eabihf target.
$ tail -n9 .cargo/config.toml
[build]
# Pick ONE of these compilation targets
# target = "thumbv6m-none-eabi"    # Cortex-M0 and Cortex-M0+
# target = "thumbv7m-none-eabi"    # Cortex-M3
# target = "thumbv7em-none-eabi"   # Cortex-M4 and Cortex-M7 (no FPU)
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)
# target = "thumbv8m.base-none-eabi"   # Cortex-M23
# target = "thumbv8m.main-none-eabi"   # Cortex-M33 (no FPU)
# target = "thumbv8m.main-none-eabihf" # Cortex-M33 (with FPU)
  1. Enter the memory region information into the memory.x file.
$ cat memory.x
/* Linker script for the STM32F303VCT6 */
MEMORY
{
  /* NOTE 1 K = 1 KiBi = 1024 bytes */
  FLASH : ORIGIN = 0x08000000, LENGTH = 256K
  RAM : ORIGIN = 0x20000000, LENGTH = 40K
}
  1. Build the template application or one of the examples.
$ cargo build

VS Code

This template includes launch configurations for debugging CortexM programs with Visual Studio Code located in the .vscode/ directory.
See .vscode/README.md for more information.
If you're not using VS Code, you can safely delete the directory from the generated project.

License

This template is licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Code of Conduct

Contribution to this crate is organized under the terms of the Rust Code of Conduct, the maintainer of this crate, the Cortex-M team, promises to intervene to uphold that code of conduct.

cortex-m-quickstart's People

Contributors

adamgreig avatar angusholder avatar antage avatar birkenfeld avatar bors[bot] avatar claymcleod avatar david-boles avatar dirbaio avatar hug-dev avatar hyperslv avatar jacobrosenthal avatar jannic avatar japaric avatar josephpenafiel avatar kitlith avatar korken89 avatar mrbuddycasino avatar newam avatar nicoretti avatar plaes avatar protomors avatar rmsc avatar rubberduck203 avatar senekor avatar ssendev avatar sstelfox avatar thalesfragoso avatar thejpster avatar therealprof avatar whitequark avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cortex-m-quickstart's Issues

GDB hangs with "Ignoring packet error, continuing..."

STR

  • Uncomment the first monitor tpiu line in .gdbinit.
 # # send captured ITM to the file itm.fifo
 # # (the microcontroller SWO pin must be connected to the programmer SWO pin)
 # # 8000000 must match the core clock frequency
-# monitor tpiu config internal itm.fifo uart off 8000000
+monitor tpiu config internal itm.fifo uart off 8000000

 # # OR: make the microcontroller SWO pin output compatible with UART (8N1)
 # # 2000000 is the frequency of the SWO pin
  • Create a named piped named itm.fifo in the directory where OpenOCD is invoked
$ cd ~/tmp
$ openocd (..)

$ # on another terminal
$ cd ~/tmp
$ mkfifo itm.fifo
  • Launch GDB using xargo run
$ xargo run
Reading symbols from target/thumbv7em-none-eabihf/debug/cortex-m-quickstart...done.
cortex_m_rt::reset_handler ()
    at /home/japaric/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-rt-0.3.12/src/lib.rs:330
330     unsafe extern "C" fn reset_handler() -> ! {
semihosting is enabled
Ignoring packet error, continuing...
Ignoring packet error, continuing...

Note that when you reach this point OpenOCD will become unresponsive and you'll have to kill it and start a new OpenOCD process before you can invoke xargo run / start GDB.

Cause

The monitor tpiu config internal itm.fifo uart off 8000000 line hangs because the named pipe is not open (I assume).

Workaround

Open the itm.fifo file before calling xargo run.

$ itmdump -f itm.fifo

$ # on another terminal
$ xargo run

Note that itmdump v0.2.0 sometimes ends when you terminate the GDB session. In that case you'll have to re-run the itmdump command before the next time you call xargo run / start GDB.

The other alternative is used a plain text file instead of a named pipe. This problem only occurs with named pipes. If you use a plain text file you can use itmdump's follow mode (-F) to get a named pipe like behavior.


I can't think of a way to avoid this problem or improve the error message from our side so at least I'm documenting the problem here. I'll add it to the troubleshooting guide as well.

Add documentation ARM v8 Baseline and Mainline (Cortex-M23/M33/M35P)

I'm getting started with a ATSAML10xxxx series project that uses Cortex M23 (ARM v8 baseline)

Since I'm new to Rust development (but already an experienced embedded developer), I've been following The Embedded Rust Book - Installing the tools. Specifically it suggests adding the following targets with rustup target add

  • thumbv6m-none-eabi
  • thumbv7m-none-eabi
  • thumbv7em-none-eabi
  • thumbv7em-none-eabihf

As for ARM v8 baseline, mainline and mainline with extension, the targets are respectively:

  • thumbv8m.base-none-eabi (e.g. Cortex M23)
  • thumbv8m.main-none-eabi (Not sure which arch uses this instruction set specifically 🤷‍♀️)
  • thumbv8m.main-none-eabihf (e.g. Cortex M33, CortexM35P)

Could these be added to README.md and also other places I've yet to come across?

- `rust-std` components (pre-compiled `core` crate) for the ARM Cortex-M
targets. Run:
``` console
$ rustup target add thumbv6m-none-eabi thumbv7m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf
```

and
``` toml
[build]
# Pick ONE of these compilation targets
# target = "thumbv6m-none-eabi" # Cortex-M0 and Cortex-M0+
# target = "thumbv7m-none-eabi" # Cortex-M3
# target = "thumbv7em-none-eabi" # Cortex-M4 and Cortex-M7 (no FPU)
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)
```

Maybe a reference to the Cortex-M comparison table might help with picking out the right instruction set

examples/device.rs doesn't make a whole lot of sense

As I've just discovered, SysTick does not generate exceptions by default and requires configuration to do so. Unfortunately the configuration can not be done without direct register manipulation since the SVDs (even the current official ones) lack the description of the required STK_ addresses.

I my opinion examples should always be a good starting point for further tinkering but in the case of SYS_TICK it's really a dead end...

Examples don't build

[matthew@ArchSystem cortex-m-quickstart]$ xargo -V
xargo 0.3.8
cargo 0.23.0-nightly (e447ac7e9 2017-09-27)
[matthew@ArchSystem cortex-m-quickstart]$ rustc -V
rustc 1.22.0-nightly (6f87d20a7 2017-09-29)

Following the steps at https://docs.rs/cortex-m-quickstart/0.2.1/cortex_m_quickstart/ results in examples that don't build.

I'm trying to build the example hello.rs:

//! Prints "Hello, world!" on the OpenOCD console using semihosting
//!
//! ---

#![feature(used)]
#![no_std]

extern crate cortex_m;
extern crate cortex_m_rt;
extern crate cortex_m_semihosting;

use core::fmt::Write;

use cortex_m::asm;
use cortex_m_semihosting::hio;

fn main() {
    let mut stdout = hio::hstdout().unwrap();
    writeln!(stdout, "Hello, world!").unwrap();
}

// As we are not using interrupts, we just register a dummy catch all handler
#[link_section = ".vector_table.interrupts"]
#[used]
static INTERRUPTS: [extern "C" fn(); 240] = [default_handler; 240];

extern "C" fn default_handler() {
    asm::bkpt();
}

And I get this error:

[matthew@ArchSystem cortex-m-quickstart]$ xargo build --target thumbv7em-none-eabihf
   Compiling vcell v0.1.0
   Compiling cortex-m-quickstart v0.2.1 (file:///home/matthew/Rust/cortex-m-quickstart)
   Compiling bare-metal v0.1.1
   Compiling r0 v0.2.2
   Compiling cortex-m v0.3.1
   Compiling cortex-m-rt v0.3.5
   Compiling aligned v0.1.1
   Compiling cortex-m-semihosting v0.2.0
   Compiling volatile-register v0.2.0
   Compiling stm32f103xx v0.7.5
error: linking with `arm-none-eabi-ld` failed: exit code: 1
  |
  = note: "arm-none-eabi-ld" "-L" "/home/matthew/.xargo/lib/rustlib/thumbv7em-none-eabihf/lib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.0.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.1.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.10.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.11.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.12.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.13.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.14.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.15.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.16.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.17.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.18.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.19.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.2.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.20.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.21.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.22.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.23.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.24.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.25.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.26.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.27.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.28.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.29.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.3.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.30.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.31.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.4.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.5.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.6.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.7.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.8.o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe.9.o" "-o" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/cortex_m_quickstart-d4d727dd7bcc42fe" "--gc-sections" "-L" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps" "-L" "/home/matthew/Rust/cortex-m-quickstart/target/debug/deps" "-L" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/build/cortex-m-quickstart-f3f9817348225d8c/out" "-L" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-90b1719ebf8fd2a6/out" "-L" "/home/matthew/.xargo/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libcortex_m_rt-084609a7eabef0b0.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libr0-139662ce822171f5.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libcortex_m_semihosting-d01acf028121f941.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libcortex_m-b6aa1a4b30b94c14.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libbare_metal-6d3be0f20e7650c5.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libaligned-4ec481963f639147.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libvolatile_register-e7853a3b6bd73682.rlib" "/home/matthew/Rust/cortex-m-quickstart/target/thumbv7em-none-eabihf/debug/deps/libvcell-87f07f6d6fae9582.rlib" "/home/matthew/.xargo/lib/rustlib/thumbv7em-none-eabihf/lib/libcore-e51a562f0b13f7ca.rlib" "/home/matthew/.xargo/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-d512a12552ca0e4c.rlib" "-Tlink.x" "-Bdynamic"
  = note: arm-none-eabi-ld: 
          The exception handlers are missing. This is likely a cortex-m-rt bug.
          Please file a bug report at:
          https://github.com/japaric/cortex-m-rt/issues
          arm-none-eabi-ld: 
          Invalid '.vector_table.exceptions' section. This is likely a
          cortex-m-rt bug. Please file a bug report at:
          https://github.com/japaric/cortex-m-rt/issues
          

error: aborting due to previous error

error: Could not compile `cortex-m-quickstart`.

To learn more, run the command again with --verbose.

Am I doing something wrong? Or is this a bug? I've only been using rust for a few months, so this could be my mistake.

Support for adding section

Hello,

I'm using the FRDM-KL25Z and it needs a "flash protection" section. I tried modifying the memory.x script as follows:

MEMORY
{
  VECTORS (rx) : ORIGIN = 0x00000000, LENGTH = 0x00000400
  FLASH_PROTECTION	(rx) : ORIGIN = 0x00000400, LENGTH = 0x00000010
  FLASH (rx) : ORIGIN = 0x00000410, LENGTH = 128K - 0x00000410
  RAM (rwx) : ORIGIN = 0x1FFFF0C0, LENGTH = 16K - 0xC0
}

SECTIONS
{
    .flash_protect :
    {
        KEEP(*(.flash_configuration))
         . = ALIGN(4);
    } > FLASH_PROTECTION

}

With the following data:

#[link_section=".flash_configuration"]
#[used]
static FLASH_CONFIG_FIELD: [u32; 4] = [
    0xFFFFFFFF,
    0xFFFFFFFF,
    0xFFFFFFFF,
    0xFFFFFFFE,
];

But after compiling and generating the .bin file, the address is not set.

screen shot 2018-04-02 at 13 54 53

I'm using the following commands to compile and generate the bin
xargo build --target thumbv6m-none-eabi --release -v
arm-none-eabi-objcopy -S -O binary ./target/thumbv6m-none-eabi/release/lab01 lab01.bin

Am I doing something wrong or is setting custom sections not supported?

The elf file works with GDB as expected, but to flash the code I need to use the bin file with the correct flash_config_field bits at 0x400.

Attached are the elf and bin files.

Thanks for the help in advance :)

lab01.elf.txt
lab01.bin.txt

__RESET_VECTOR has an invalid section specifier

What am I missing?

cargo build --examples
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling cc v1.0.17                                                         
   Compiling vcell v0.1.0
   Compiling aligned v0.2.0
   Compiling bare-metal v0.2.0
   Compiling r0 v0.2.2
   Compiling cortex-m-quickstart v0.3.2 (file:///~/sources/cortex-m-qs)
   Compiling volatile-register v0.2.0
   Compiling cortex-m v0.5.2
   Compiling cortex-m-semihosting v0.3.0
   Compiling cortex-m-rt v0.5.1
LLVM ERROR: Global variable '__RESET_VECTOR' has an invalid section specifier '.vector_table.reset_vector': mach-o section specifier requires a segment whose length is between 1 and 16 characters.
error: Could not compile `cortex-m-rt`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Updating the nightly doesn't help:

rustup toolchain install nightly
info: syncing channel updates for 'nightly-x86_64-apple-darwin'
info: latest update on 2018-06-20, rust version 1.28.0-nightly (f28c7aef7 2018-06-19)
info: downloading component 'rustc'
 57.2 MiB /  57.2 MiB (100 %)   8.9 MiB/s ETA:   0 s                
info: downloading component 'rust-std'
 46.9 MiB /  46.9 MiB (100 %)  11.1 MiB/s ETA:   0 s                
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: downloading component 'rust-std' for 'thumbv7em-none-eabihf'
info: downloading component 'rust-std' for 'thumbv7m-none-eabi'
info: downloading component 'rls-preview'
info: downloading component 'rust-analysis'
info: downloading component 'rust-src'
info: removing component 'rustc'
info: removing component 'rust-std'
info: removing component 'cargo'
info: removing component 'rust-docs'
info: removing component 'rust-std' for 'thumbv7em-none-eabihf'
info: removing component 'rust-std' for 'thumbv7m-none-eabi'
info: removing component 'rls-preview'
info: removing component 'rust-analysis'
info: removing component 'rust-src'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: installing component 'rust-std' for 'thumbv7em-none-eabihf'
info: installing component 'rust-std' for 'thumbv7m-none-eabi'
info: installing component 'rls-preview'
info: installing component 'rust-analysis'
info: installing component 'rust-src'

  nightly-x86_64-apple-darwin updated - rustc 1.28.0-nightly (f28c7aef7 2018-06-19)

Linking issues when building for cortex-m0

xargo 0.3.12
cargo 1.30.0-nightly (2fb77a49b 2018-09-07)
cortex-m-quickstart: 0.3.4
target: "thumbv6m-none-eabi"

Compiling for any target with thumbv7 seems to work fine

$ xargo build --example hello
.....
= note: rust-lld: error: undefined symbol: __clzsi2
>>> referenced by core.7aqqco4c-cgu.0
>>> core-4798f6087bcbc344.core.7aqqco4c-cgu.0.rcgu.o:(_$LT$char$u20$as$u20$core..fmt..Debug$GT$::fmt::h347e39ad26aec4d0) in archive /home/roel/.xargo/lib/rustlib/thumbv6m-none-eabi/lib/libcore-4798f6087bcbc344.rlib

Update for stm32l4 dependency causes linker error

I update follwing files for using STM32L476

  • Cargo.toml
[dependencies.stm32l4]
features = ["stm32l4x6", "rt"]
version = "0.11.0"
  • config
[build]
# Pick ONE of these compilation targets
# target = "thumbv6m-none-eabi"    # Cortex-M0 and Cortex-M0+
# target = "thumbv7m-none-eabi"    # Cortex-M3
# target = "thumbv7em-none-eabi"     # Cortex-M4 and Cortex-M7 (no FPU)
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)
  • memory.x
MEMORY
{
  /* NOTE 1 K = 1 KiBi = 1024 bytes */
  /* TODO Adjust these memory regions to match your device memory layout */
  /* These values correspond to the LM3S6965, one of the few devices QEMU can emulate */
  FLASH : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM : ORIGIN = 0x20000000, LENGTH = 96K
}
  • examples/device.rs
use stm32l4::stm32l4x6::{interrupt, Interrupt, NVIC};

Then, I compline device cargo build --example device is finish. After that, I complie hello 'cargo build --example hello'. But it happen a build error.

/mnt/rust/src/app# cargo build --example hello
   Compiling awesome-app v0.1.0 (/mnt/rust/src/app)
warning: unused import: `debug`
 --> examples/hello.rs:9:28
  |
9 | use cortex_m_semihosting::{debug, hprintln};
  |                            ^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/usr/local/rustup/toolchains/1.45.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/examples/hello-8f9cd6364696548c.2qm8sestblbxkequ.rcgu.o" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/examples/hello-8f9cd6364696548c.2x4nait49zpt1oyp.rcgu.o" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/examples/hello-8f9cd6364696548c.3fqpxmhbeby0vnr9.rcgu.o" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/examples/hello-8f9cd6364696548c.5cvtkejs45hfcola.rcgu.o" "-o" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/examples/hello-8f9cd6364696548c" "--gc-sections" "-L" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps" "-L" "/mnt/rust/src/app/target/debug/deps" "-L" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/build/awesome-app-b6d72e815af4ef45/out" "-L" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/build/cortex-m-25ad3822f8a7a2a8/out" "-L" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-dc75f42577b5d9d9/out" "-L" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/build/cortex-m-semihosting-6a1c39732392316c/out" "-L" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/build/stm32l4-6cc22a755524db5d/out" "-L" "/usr/local/rustup/toolchains/1.45.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libcortex_m_semihosting-41ed8b6732571890.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libcortex_m-4a546d3f8fe96189.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libvolatile_register-931097aba76b036e.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libvcell-5ad610f7cd60d5ba.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libbare_metal-1389f903efc94440.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libaligned-9a89ddbd462d1e07.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libas_slice-377848fecaa59fea.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libstable_deref_trait-a11f983656b18d1d.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libgeneric_array-b93168bf128964f5.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libgeneric_array-b284d275589af3fb.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libtypenum-fc489d0bc1f0e902.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libcortex_m_rt-3e88d67a44ef2c5c.rlib" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libr0-2ddfb6c5c3292139.rlib" "--start-group" "/mnt/rust/src/app/target/thumbv7em-none-eabihf/debug/deps/libpanic_halt-d35b0c7ceab6b642.rlib" "/usr/local/rustup/toolchains/1.45.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/librustc_std_workspace_core-3370a0a65a1e95ca.rlib" "/usr/local/rustup/toolchains/1.45.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcore-688cc81889ae99dc.rlib" "--end-group" "/usr/local/rustup/toolchains/1.45.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-7b0ac0a4cad7c4db.rlib" "-Tlink.x" "-Bdynamic"
  = note: rust-lld: error: 
          ERROR(cortex-m-rt): The interrupt vectors are missing.
          Possible solutions, from most likely to less likely:
          - Link to a svd2rust generated device crate
          - Disable the 'device' feature of cortex-m-rt to build a generic application (a dependency
          may be enabling it)
          - Supply the interrupt handlers yourself. Check the documentation for details.
          
          rust-lld: error: 
          ERROR(cortex-m-rt): The interrupt vectors are missing.
          Possible solutions, from most likely to less likely:
          - Link to a svd2rust generated device crate
          - Disable the 'device' feature of cortex-m-rt to build a generic application (a dependency
          may be enabling it)
          - Supply the interrupt handlers yourself. Check the documentation for details.
          
          rust-lld: error: 
          ERROR(cortex-m-rt): The interrupt vectors are missing.
          Possible solutions, from most likely to less likely:
          - Link to a svd2rust generated device crate
          - Disable the 'device' feature of cortex-m-rt to build a generic application (a dependency
          may be enabling it)
          - Supply the interrupt handlers yourself. Check the documentation for details.
          

error: aborting due to previous error; 1 warning emitted

Is this sorce code support STM32L476?

Update to latest cortex-m?

I notice that hprintln! is missing from the later versions of the cortex-m crate. Is there a replacement?

VSCode GDB Launch Configuration Not Taken From `openocd.gdb`

Would it be possible to configure the VSCode cortex-debug extension to pull its gdb commands from openocd.gdb? I ran into this when trying to use semihosting, openocd.gdb enables it but the cortex-debug launch configuration doesn't. If not (I couldn't see how), should I make a pull request to add "preLaunchCommands": ["monitor arm semihosting enable"] to the launch configurations?

License files missing

README.md contains links to files named LICENSE-APACHE and LICENSE-MIT. Neither file is present in the source tree. This makes it impossible to correctly use the MIT license as the copyright year and holder are unknown.

Release build crashes

If I build this project with --release for thumbv7em-none-eabi, I end up in the Hardfault handler.

If I add an asm::nop(); to the loop { } in main, it works fine. It's fine as a debug either with or without the asm::nop().

I'm using a TM4C129 Launchpad, but haven't extern'd in a chip crate yet. I've attached the generated assembly.

test_app.txt

memory.x contains incorrect FLASH : ORIGIN value

MEMORY
{
/* NOTE 1 K = 1 KiBi = 1024 bytes /
/
TODO Adjust these memory regions to match your device memory layout /
/
These values correspond to the LM3S6965, one of the few devices QEMU can emulate */
FLASH : ORIGIN = 0x00000000, LENGTH = 256K <- Value in source code
RAM : ORIGIN = 0x20000000, LENGTH = 40K
}

but had to change to

MEMORY
{
/* NOTE 1 K = 1 KiBi = 1024 bytes /
/
TODO Adjust these memory regions to match your device memory layout /
/
These values correspond to the LM3S6965, one of the few devices QEMU can emulate */
FLASH : ORIGIN = 0x08000000, LENGTH = 256K
RAM : ORIGIN = 0x20000000, LENGTH = 40K
}

then I was able to load the code onto the microcontroller.

Using Rev C+ of the STM32f3xDiscovery board, but that shouldn't be an issue.

"message": "failed to parse manifest at `/Users/tz/Downloads/cortex-m-quickstart-master/Cargo.toml`",

tz@taodeMacBook-Pro cortex-m-quickstart-master % cargo build --target thumbv7m-none-eabi
error: failed to parse manifest at /Users/tz/Downloads/cortex-m-quickstart-master/Cargo.toml

Caused by:
invalid character { in package name: {{project-name}}, the first character must be a Unicode XID start character (most letters or _)
tz@taodeMacBook-Pro cortex-m-quickstart-master %

"/Users/tz/Downloads/cortex-m-quickstart-master/Cargo.toml", "owner": "rust-file:///Users/tz/Downloads/cortex-m-quickstart-master", "severity": 8, "message": "failed to parse manifest at /Users/tz/Downloads/cortex-m-quickstart-master/Cargo.toml", "startLineNumber": 1, "startColumn": 1, "endLineNumber": 10000, "endColumn": 1 }]

link error when building for debug, works with --release

This works: xargo build --release --target thumbv7m-none-eabi -v
But without --release I get:

error: linking with arm-none-eabi-ld failed: exit code: 1
....
= note: arm-none-eabi-ld:
You must specify the exception handlers.
Create a non pub static variable with type
cortex_m::exception::Handlers and place it in the
'.rodata.exceptions' section. (cf. #[link_section]). Apply the
#[used] attribute to the variable to make it reach the linker.
arm-none-eabi-ld:
Invalid '.rodata.exceptions' section.
Make sure to place a static with type cortex_m::exception::Handlers
in that section (cf. #[link_section]) ONLY ONCE.

Same error as in your FAQ but different cause?

Rookie to rust. My dev environment is in a vagga container https://github.com/bootchk/rustDevContainers rustNordicBlinky. The container script follows your tutorial more or less, for Nordic nrf52832. I get a blinky.rs to compile and load to a NRF52DK board, but it doesn't blink yet.

Add a way of unittesting

Would it be possible for someone with experience in such, to add some examples of adding unit testing and possibly integration testing to a project like this?

Maybe even using https://github.com/japaric/utest to allow qemu emulations?

I myself is struggling a lot to work it out, but i don't think it is very simple.. Or at least not very well documented.

Exception override

What would be the example syntax to replace a default exception now? In particular SysTick. It isn't a big problem as I switched to a Timx periodic interrupt for the time being. Huge thanks to you for so much good useful work on Rust embedded!

'eh_personality' not found when building from another directory

Problem

When a cortex-m-quickstart project is built from another directory using
cargo build --manifest-path=oof-test/Cargo.toml
command it fails with the following output:

[hug-dev@machine tmp]$ cargo build --manifest-path=oof-test/Cargo.toml
   Compiling semver-parser v0.7.0
   Compiling proc-macro2 v0.4.26
   Compiling unicode-xid v0.1.0
   Compiling rand_core v0.4.0
   Compiling vcell v0.1.0
   Compiling cortex-m v0.5.8
   Compiling aligned v0.2.0
   Compiling cortex-m-semihosting v0.3.2
   Compiling cortex-m-rt v0.6.7
   Compiling r0 v0.2.2
   Compiling oof-test v0.1.0 (/tmp/oof-test)
   Compiling panic-halt v0.2.0
   Compiling volatile-register v0.2.0
   Compiling rand_core v0.3.1
   Compiling rand v0.5.6
   Compiling semver v0.9.0
   Compiling rustc_version v0.2.3
   Compiling bare-metal v0.2.4
   Compiling quote v0.6.11
   Compiling syn v0.15.26
   Compiling cortex-m-rt-macros v0.1.5
error: language item required, but not found: `eh_personality`

error: aborting due to previous error

error: Could not compile `oof-test`.

To learn more, run the command again with --verbose.

How to reproduce

  • rustc 1.34.0-nightly (147311c5f 2019-01-30)
  • cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart
  • Project name: oof-test
  • cargo build --manifest-path=oof-test/Cargo.toml

Why is it a problem?

I would like to create a Rust workspace with multiple cortex-m-quickstart projects, but because of that I can not. The workaround I did is to have a script that pushd into the Cargo projects and cargo build from there. Could be nice to have that working!

stm32l432kc flash problem with quickstart template

I have a stm32l432kc and I started a new project with cortex-m-quickstart template. I can build and the with openocd but I have a problem to flash (or load) the binary into the nucleo.

//! Blinks an LED
#![no_std]
#![no_main]

use core::panic::PanicInfo;

extern crate cortex_m;
#[macro_use]
extern crate cortex_m_rt as rt;
extern crate cortex_m_semihosting as sh;
extern crate stm32l4xx_hal as hal;

use crate::hal::prelude::*;
use crate::hal::delay::Delay;
use crate::rt::ExceptionFrame;
use crate::rt::entry;

use core::fmt::Write;
use crate::sh::hio;

#[inline(never)]
#[entry]
fn main() -> ! {

    let mut hstdout = hio::hstdout().unwrap();

    writeln!(hstdout, "Hello, world!").unwrap();

    let cp = cortex_m::Peripherals::take().unwrap();
    let dp = hal::stm32::Peripherals::take().unwrap();

    let mut flash = dp.FLASH.constrain(); // .constrain();
    let mut rcc = dp.RCC.constrain();

    // Try a different clock configuration
    let clocks = rcc.cfgr.hclk(8.mhz()).freeze(&mut flash.acr);
    
    let mut gpiob = dp.GPIOA.split(&mut rcc.ahb2);
    let mut led = gpiob.pa1.into_push_pull_output(&mut gpiob.moder, &mut gpiob.otyper);

    let mut gpiof = dp.GPIOB.split(&mut rcc.ahb2);
    let mut leda = gpiof.pb3.into_push_pull_output(&mut gpiof.moder, &mut gpiof.otyper);

    let mut timer = Delay::new(cp.SYST, clocks);
    loop {
        timer.delay_ms(100 as u32);
        
        led.set_high();
        leda.set_high();
        
        timer.delay_ms(100 as u32);
        
        led.set_low();
        leda.set_low();
        
        writeln!(hstdout, "ciao").unwrap();
    }
}

#[panic_handler]
#[no_mangle]
pub fn panic(_info: &PanicInfo) -> ! {
    loop{}
}
[package]
authors = ["luca"]
edition = "2018"
readme = "README.md"
name = "app"
version = "0.1.0"

[dependencies]
cortex-m = "0.6.1"
cortex-m-rt = "0.6.10"
cortex-m-semihosting = "0.3.3"
panic-halt = "0.2.0"
alloc-cortex-m = "0.3.5"
embedded-hal = "0.2.1"
generic-array = "0.12.0"
nb = "0.1.0"

[dependencies.stm32l4xx-hal]
version = "0.5.0"
features = ["stm32l4x2"]

[dependencies.stm32l4]
version = "0.8.0"
features = ["stm32l4x2", "rt"]

[dependencies.cast]
default-features = false
version = "0.2.2"

# this lets you use `cargo fix`!
[[bin]]
name = "app"
test = false
bench = false

[profile.release]
codegen-units = 1 # better optimizations
debug = false # symbols are nice and they don't increase the size on Flash
lto = true # better optimizations
panic = "abort"
opt-level = 's'

#[profile.dev]
#panic = "abort"

The memory.x is

MEMORY
{
  /* NOTE K = KiBi = 1024 bytes */
  FLASH : ORIGIN = 0x08000000, LENGTH = 256K
  RAM : ORIGIN = 0x20000000, LENGTH = 40K
}

/* This is where the call stack will be allocated. */
/* The stack is of the full descending type. */
/* You may want to use this variable to locate the call stack and static
   variables in different memory regions. Below is shown the default value */
/* _stack_start = ORIGIN(RAM) + LENGTH(RAM); */

/* You can use this symbol to customize the location of the .text section */
/* If omitted the .text section will be placed right after the .vector_table
   section */
/* This is required only on microcontrollers that store some configuration right
   after the vector table */
/* _stext = ORIGIN(FLASH) + 0x400; */

/* Example of putting non-initialized variables into custom RAM locations. */
/* This assumes you have defined a region RAM2 above, and in the Rust
   sources added the attribute `#[link_section = ".ram2bss"]` to the data
   you want to place there. */
/* Note that the section will not be zero-initialized by the runtime! */
/* SECTIONS {
     .ram2bss (NOLOAD) : ALIGN(4) {
       *(.ram2bss);
       . = ALIGN(4);
     } > RAM2
   } INSERT AFTER .bss;
*/

If I inspect app I can see

arm-none-eabi-readelf -h app

ELF Header:                                                                     
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00                      
  Class:                             ELF32                                      
  Data:                              2's complement, little endian              
  Version:                           1 (current)                                
  OS/ABI:                            UNIX - System V                            
  ABI Version:                       0                                          
  Type:                              EXEC (Executable file)                     
  Machine:                           ARM                                        
  Version:                           0x1                                        
  Entry point address:               0x80004a3                                  
  Start of program headers:          52 (bytes into file)                       
  Start of section headers:          49632 (bytes into file)                    
  Flags:                             0x5000400, Version5 EABI, hard-float ABI   
  Size of this header:               52 (bytes)                                 
  Size of program headers:           32 (bytes)                                 
  Number of program headers:         3                                          
  Size of section headers:           40 (bytes)                                 
  Number of section headers:         21                                         
  Section header string table index: 19                                         

But the "same" functionality produces in Arduino something like this:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x80002ad
  Start of program headers:          52 (bytes into file)
  Start of section headers:          149912 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         3
  Size of section headers:           40 (bytes)
  Number of section headers:         18

The difference here is the Entry point address. If I try to copy

arm-none-eabi-objcopy -O binary app app.bin
cp app.bin /run/media/luca/NODE_L432KC

The binary produced by rust does not start.

Using probe-rs to initialise memory.x

Wouldn't it be great to automatically create a proper linker configuration based on the selected chip? It seems that this information can be easily pulled from yaml files in probe-rs/targets/. Probably someone is already thought about it, in that case just close this right away.

Error while following the Embedded Book

Qemu section Using cargo-generate

While creating project from template I get an error:

$ cargo install cargo-generate --git https://github.com/rust-embedded/cortex-m-quickstart
    Updating git repository `https://github.com/rust-embedded/cortex-m-quickstart`
error: failed to parse manifest at `/home/dtomasgu/.cargo/git/checkouts/cortex-m-quickstart-e5c41c227d09013e/6b2fd0e/Cargo.toml`

Caused by:
  invalid character `{` in package name: `{{project-name}}`, the first character must be a Unicode XID start character (most letters or `_`)

$ cargo --version
cargo 1.68.1 (115f34552 2023-02-26)

Is it possible to run examples in `qemu`?

I have tried running rp pico (Cortex M0+) in qemu-system-arm with no luck (ref). I expected other processor to have better support in qemu so I compiled hello.rs example of for Cortex M3 but I can't get that to work either:

$ qemu-system-arm -M stm32vldiscovery -kernel target/thumbv7m-none-eabi/debug/examples/hello -nographic -serial tcp::5678,server=on
QEMU 6.2.0 monitor - type 'help' for more information
(qemu) qemu-system-arm: -serial tcp::5678,server=on: info: QEMU waiting for connection on: disconnected:tcp:0.0.0.0:5678,server=on
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

R00=2000ffe0 R01=00000004 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=2000ffe0 R14=fffffff9 R15=00001454
XPSR=41000003 -Z-- T handler
FPSCR: 00000000
fish: Job 2, 'qemu-system-arm -M stm32vldisco…' terminated by signal SIGABRT (Abort)

other variants I have tried:

$ qemu-system-arm -M stm32vldiscovery -cpu cortex-m3  -kernel target/thumbv7m-none-eabi/debug/examples/hello -nographic -serial tcp::5678,server=on

$ arm-none-eabi-objcopy target/thumbv7m-none-eabi/debug/examples/hello -O ihex helloi.hex
$ qemu-system-arm -M stm32vldiscovery -cpu cortex-m3 -kernel  helloi.hex -nographic -serial tcp::5678,server=on

none works. I need a way to verify my lib works on target CPU without running hardware first, there are a lot of iterations involved and testing on hardware directly is not feasible. Is there a way for this?

Failed to launch GDB error

Hello there! I'm completely new to ARM, and I'm relatively new to Rust, too.
I started the Discovery book a few days ago with an STM32F3DISCOVERY board and I was able to run some of the examples on my board and debug them in VSCode without any problem (or at least I solved them all) but when I decided to use this quickstart, I can't make it work. I just generated a project based on this repository and I just changed the config file but when I start debugging, the VSCode shows an error:

Failed to launch GDB: Cannot access memory at address 0xe000edfc (from interpreter-exec console "EnableITMAccess")

In the Debug Console tab, I have:

Open On-Chip Debugger 0.10.0 (2019-08-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J27M15 (API v2) VID:PID 0483:374B
Info : Target voltage: 2.921552
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
Info : device id = 0x10036422
Info : flash size = 256kbytes
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800386c msp: 0x10002000
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800386c msp: 0x10002000

And in the Output tab I have:

Please check OUTPUT tab (Adapter Output) for output from openocd.exe
Launching server: "openocd.exe" "-c" "gdb_port 50000" "-s" "C:\Users\Mehrdad\Desktop\Rust\ARM\stm32f3discovery-start" "-f" "interface/stlink-v2-1.cfg" "-f" "target/stm32f3x.cfg" "-c" "tpiu config internal C:/Users/Mehrdad/AppData/Local/Temp/tmp-11256CKNOTpJ7MMc0 uart off 8000000 2000000"
Launching GDB: "arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2"
undefinedC:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
Reading symbols from C:\Users\Mehrdad\Desktop\Rust\ARM\stm32f3discovery-start\target\thumbv7em-none-eabihf\debug\stm32f3discovery-start...
0x0800386c in ?? ()
Not implemented stop reason (assuming exception): undefined
Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800386c msp: 0x10002000
Load failed
Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800386c msp: 0x10002000
Cannot access memory at address 0xe000edfc

I don't know what's happening. I'm using Windows 10 and OpenOCD from Chocolatey, and here's what I changed from the config file:

runner = "arm-none-eabi-gdb -q -x openocd.gdb"
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)

That's it. I don't know what happens because I have very little knowledge about ARM or OpenOCD or GDB, and I'm stuck. Your help is really appreciated.

VS Code: Add release profile task

With the provided VS Code build task, I end up with an unoptimized debug build. Could a new task be added for the "release" profile?

(I can't figure out the syntax for specified arguments to a "cargo" task type, but did get it working by changing it to use the "process" type. Perhaps this is a limitation of the RLS plugin?)

The following task works for me (but I don't know if it is the desired solution):

        {
            "label": "build_release",
            "type": "process",
            "command": "cargo",
            "args": ["build", "--release"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$rustc"
            ]
        }

add a runner to flash program directly

Can we add a runner to flash program directly through openocd? It can be annoying to start openocd and close gdb manually every time you flash.

In fact, I did this in my own project:

  1. Add runner = "./flash.sh" to config.toml
  2. Create a flash.sh in the project root directory, and its contents are:
openocd -f openocd.cfg -c init -c halt -c "flash write_image erase $1" -c reset -c shutdown

Then I can flash the program directly with cargo run. This may not be a good way to implement it, but it's really convenient.

cargo build fails: can't find crate for `std`

The output of the error is the following:

   Compiling rust-toolchain v0.1.0 (/tmp/test)                                                                                                                                       
     Running `rustc --crate-name rust_toolchain src/main.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=f8ada62e29834902 -C extra-filename=-f8ada62e29834902 --out-dir /tmp/test/target/thumbv7em-none-eabihf/debug/deps --target thumbv7em-none-eabihf -C incremental=/tmp/test/target/thumbv7em-none-eabihf/debug/incremental -L dependency=/tmp/test/target/thumbv7em-none-eabihf/debug/deps -L dependency=/tmp/test/target/debug/deps --extern stm32f3=/tmp/test/target/thumbv7em-none-eabihf/debug/deps/libstm32f3-89c96bc170109bc0.rlib -C link-arg=-Tlink.x -L /tmp/test/target/thumbv7em-none-eabihf/debug/build/stm32f3-7c665be50e2d2105/out -L '/home/wucke13/documents/people/Günther Kemnitz/rust-toolchain/target/thumbv7em-none-eabihf/debug/build/cortex-m-e093635255097b24/out' -L /tmp/test/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-28a646978498040b/out`
error[E0463]: can't find crate for `std`                                                                                                                                             
  |                                                                                                                                                                                  
  = note: the `thumbv7em-none-eabihf` target may not be installed                                                                                                                    
                                                                                                                                                                                     
error: aborting due to previous error                                                                                                                                                
                                                                                                                                                                                     
For more information about this error, try `rustc --explain E0463`.                                                                                                                  
error: Could not compile `rust-toolchain`.                                                                                                                                           

Caused by:
  process didn't exit successfully: `rustc --crate-name rust_toolchain src/main.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=f8ada62e29834902 -C extra-filename=-f8ada62e29834902 --out-dir /tmp/test/target/thumbv7em-none-eabihf/debug/deps --target thumbv7em-none-eabihf -C incremental=/tmp/test/target/thumbv7em-none-eabihf/debug/incremental -L dependency=/tmp/test/target/thumbv7em-none-eabihf/debug/deps -L dependency=/tmp/test/target/debug/deps --extern stm32f3=/tmp/test/target/thumbv7em-none-eabihf/debug/deps/libstm32f3-89c96bc170109bc0.rlib -C link-arg=-Tlink.x -L /tmp/test/target/thumbv7em-none-eabihf/debug/build/stm32f3-7c665be50e2d2105/out -L '/home/wucke13/documents/people/Günther Kemnitz/rust-toolchain/target/thumbv7em-none-eabihf/debug/build/cortex-m-e093635255097b24/out' -L /tmp/test/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-28a646978498040b/out` (exit code: 1)

rustup show shows that the needed target is installed, though:

Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
beta-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf
thumbv7m-none-eabi
x86_64-unknown-linux-gnu

active toolchain
----------------

beta-x86_64-unknown-linux-gnu (default)
rustc 1.31.0-beta.8 (9142ac95a 2018-11-10)

What causes this?

LLVM ERROR: Unexpected anonymous function when writing summary

Compiling cortex-m-quickstart when following the guide in the documentation results in the following:

$ xargo build --release

LLVM ERROR: Unexpected anonymous function when writing summary
error: Could not compile compiler_builtins.

Caused by:
process didn't exit successfully: rustc --crate-name compiler_builtins /home/raz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C codegen-units=1 -C debuginfo=2 --cfg feature="compiler-builtins" --cfg feature="default" --cfg feature="mem" -C metadata=3f2fd4d5819eb5d9 -C extra-filename=-3f2fd4d5819eb5d9 --out-dir /tmp/xargo.wiFZ2xMeLRgJ/target/thumbv7em-none-eabihf/release/deps --target thumbv7em-none-eabihf -L dependency=/tmp/xargo.wiFZ2xMeLRgJ/target/thumbv7em-none-eabihf/release/deps -L dependency=/tmp/xargo.wiFZ2xMeLRgJ/target/release/deps -C link-arg=-Wl,-Tlink.x -C link-arg=-nostartfiles --sysroot /home/raz/.xargo -Z force-unstable-if-unmarked --cfg thumb (exit code: 1)
error: "cargo" "build" "--release" "--manifest-path" "/tmp/xargo.wiFZ2xMeLRgJ/Cargo.toml" "--target" "thumbv7em-none-eabihf" "-v" "-p" "compiler_builtins" failed with exit code: Some(101)

Target is thumbv7-none-eabihf.
Rustc is 1.28.0-nightly (e3bf634e0 2018-06-28).
compiler-builtins is v0.1.0.

Compiling compiler-builtins by itself with xargo build --release --target thumbv7em-none-eabihf completes with no errors.

How to run the quickstart code on LPCXpresso55S69?

I am trying to run the sample code on my LPCXpresso55S69 board. My goal is just to print "in main" on my terminal through main function. I am using following jlink.gdb

# source .gdb-dashboard
set history save on
set confirm off
set pagination off
define rebootloop
  while (1)
    run
  end
end

target extended-remote :2331
load
monitor reset
monitor semihosting enable
monitor semihosting IOClient 3
continue

My main.rs code is:

#![no_std]
#![no_main]

#[macro_use]
extern crate delog;
generate_macros!();

// pick a panicking behavior
use panic_halt as _; // you can put a breakpoint on `rust_begin_unwind` to catch panics
// use panic_abort as _; // requires nightly
// use panic_itm as _; // logs messages over ITM; requires ITM support
// use panic_semihosting as _; // logs messages to the host stderr; requires a debugger

use cortex_m::asm;
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    // asm::nop(); // To not have main optimize to abort in release mode, remove when you add code
    info_now!("In main");

    loop {
        // your code goes here
    }
}

When I run code, it does not print anything and goes in the forever loop. I tried to add a breakpoint at "info_now!("In main");" but even after breakpoint, it always goes to loop. I am assuming my memory.x might be messed up.
memory.x

MEMORY
{
  /* NOTE 1 K = 1 KiBi = 1024 bytes */
  /* TODO Adjust these memory regions to match your device memory layout */
  /* These values correspond to the LM3S6965, one of the few devices QEMU can emulate */
    FLASH : ORIGIN = 0x00000000, LENGTH = 512K

    FILESYSTEM: ORIGIN = 0x00080000, LENGTH = 118K

    /* for use with standard link.x */
    RAM : ORIGIN = 0x20000000, LENGTH = 256K
}

terminal output:

cargo run --release --features log-all,log-info,log-semihosting
warning: unused import: `cortex_m::asm`
  --> src/main.rs:14:5
   |
14 | use cortex_m::asm;
   |     ^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

warning: `test-rust-cortex-app` (bin "test-rust-cortex-app") generated 1 warning (run `cargo fix --bin "test-rust-cortex-app"` to apply 1 suggestion)
    Finished release [optimized + debuginfo] target(s) in 0.08s
     Running `arm-none-eabi-gdb -q -x jlink.gdb target/thumbv8m.main-none-eabi/release/test-rust-cortex-app`
Reading symbols from target/thumbv8m.main-none-eabi/release/test-rust-cortex-app...
test_rust_cortex_app::__cortex_m_rt_main () at /Users/tarun.yadav/Desktop/test-rust-cortex-app/src/main.rs:22
22	    loop {
Loading section .vector_table, size 0x400 lma 0x0
Loading section .text, size 0x27c lma 0x400
Start address 0x00000400, load size 1660
Transfer rate: 13280 bits in <1 sec, 830 bytes/write.
Resetting target
Semi-hosting enabled (Handle on breakpoint instruction hit)
Semihosting I/O set to TELNET and GDB Client
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
cortex_m_rt::Reset () at src/lib.rs:526
526	        () => main(),
(gdb) break main.rs:18
Breakpoint 1 at 0x3c (2 locations)
(gdb) run
Starting program: /Users/tarun.yadav/Desktop/test-rust-cortex-app/target/thumbv8m.main-none-eabi/release/test-rust-cortex-app 
[New Thread 57005]
[Switching to Thread 57005]

Thread 2 hit Breakpoint 1, test_rust_cortex_app::__cortex_m_rt_main () at /Users/tarun.yadav/Desktop/test-rust-cortex-app/src/main.rs:22
22	    loop {

Feature request: Confusing task names

Hi,

I didn't have much experience with VSCode before using it with Rust. I was working with Cortex-Debug and the preLaunchTask field. The current Rust task names look like shell commands. Because of that, I assumed I could change the preLaunchTask string to a different shell command and it would work. I only realized later that the preLaunchTask string is actually a task name, and that the task names just happen to look like shell commands.

I think this is misleading and probably a source of confusion for others who are not familiar with VSCode tasks. Can I suggest changing the names to something that doesn't look like a shell command?

probe-rs

I'm currently preparing a PR to migrate the Embedded Rust Book from OpenOCD / semihosting to probe-rs / RTT. Would it be okay to replace the openocd config and semihosting dependencies with an Embed.toml as cargo-embed config as well as https://crates.io/crates/rtt-target? Or is there any blocker for this?

Would be happy to PR it myself, should there be no blockers.

Update panic-semihosting version in generated Cargo.toml

At the moment, cortex-m-quickstart generates a Cargo.toml that includes a dependency on panic-semihosting version 0.3.0

This leads to an error when building:

error[E0557]: feature has been removed
  --> /Users/declan/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-semihosting-0.3.0/src/lib.rs:59:12
   |
59 | #![feature(panic_implementation)]
   |            ^^^^^^^^^^^^^^^^^^^^
   |
note: subsumed by `#[panic_handler]` 

If the version of panic-semihosting is changed to 0.5.2, then the generated program builds as per the instructions in the documentation.

[RFC] recommend rust-lld as the default linker

once the unstable flag -Z linker-flavor is not required

Advantages:

  • No need to install arm-none-eabi-gcc to build binaries.

Disadvantages:

  • Linking to system C libraries (e.g. newlib) requires passing the library search path, which varies per build system, to the linker. If you want to do this it's actually easier to use gcc.

cc @rust-embedded/cortex-m

Blue Pill Quickstart

Just wanted to say thanks for putting this out there, was a tremendous help.

I derived a Blue Pill Quickstart from it with VS Code debugging working great: https://github.com/reneherrero/blue-pill-quickstart

I though about doing a PR to give something back, but I don't see how to do so without creating clutter... lots of possible permutations in this area.

Anyhow, let me know if you're interested and I'll try to cook something up.

Again, thanks!

panic-semihosting should be v0.3.0 with latest nightly

It failed with the error mentioned in: https://users.rust-lang.org/t/psa-breaking-change-panic-fmt-language-item-removed-in-favor-of-panic-implementation/17875

   Compiling panic-semihosting v0.2.0
error[E0522]: definition of an unknown language item: `panic_fmt`
  --> /Users/<user>/.cargo/registry/src/github.com-.../panic-semihosting-0.2.0/src/lib.rs:67:1
   |
67 | #[lang = "panic_fmt"]
   | ^^^^^^^^^^^^^^^^^^^^^ definition of unknown language item `panic_fmt`

Updating to v0.3.0 solves the issue.

Documentation or example for the allocator not working

The documentation appears to be out of date. If I follow the steps then, to build the allocator example, I get the following error:

% cargo build --example allocator         
   Compiling typenum v1.12.0
   Compiling version_check v0.9.2
   Compiling semver-parser v0.7.0
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling cortex-m v0.6.3
   Compiling syn v1.0.42
   Compiling stable_deref_trait v1.2.0
   Compiling vcell v0.1.2
   Compiling cortex-m-semihosting v0.3.5
   Compiling volatile-register v0.1.2
   Compiling bitfield v0.13.2
   Compiling cortex-m-rt v0.6.13
   Compiling test v0.1.0 (/Users/huntc/Desktop/test/test)
   Compiling r0 v0.2.2
   Compiling linked_list_allocator v0.6.6
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /Users/huntc/.cargo/registry/src/github.com-1ecc6299db9ec823/linked_list_allocator-0.6.6/src/lib.rs:1:1
  |
1 | #![feature(const_fn)]
  | ^^^^^^^^^^^^^^^^^^^^^
...

If I try with the nightly:

huntc@Christophers-MacBook-Pro test % cargo +nightly build --example allocator
   Compiling typenum v1.12.0
   Compiling semver-parser v0.7.0
   Compiling version_check v0.9.2
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling cortex-m v0.6.3
   Compiling syn v1.0.42
   Compiling stable_deref_trait v1.2.0
   Compiling vcell v0.1.2
   Compiling cortex-m-semihosting v0.3.5
   Compiling volatile-register v0.1.2
   Compiling cortex-m-rt v0.6.13
   Compiling bitfield v0.13.2
   Compiling linked_list_allocator v0.6.6
   Compiling test v0.1.0 (/Users/huntc/Desktop/test/test)
   Compiling r0 v0.2.2
error[E0432]: unresolved import `alloc::alloc::AllocErr`
  --> /Users/huntc/.cargo/registry/src/github.com-1ecc6299db9ec823/linked_list_allocator-0.6.6/src/lib.rs:14:30
   |
14 | use alloc::alloc::{AllocRef, AllocErr, Layout};
   |                              ^^^^^^^^
   |                              |
   |                              no `AllocErr` in `alloc`
   |                              help: a similar name exists in the module: `AllocError`
...

Any pointers no how to see that the allocator example is able to be built? Is the documentation/example out of date?

Uncommenting stm32f3 dependency causes linker error

setting the runner to:

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "arm-none-eabi-gdb -q -x openocd.gdb"

# and build to
[build]
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)

and un-commenting:

[dependencies.stm32f3]
features = ["stm32f303", "rt"]
version = "0.7.1"

is all that's required to generate a build error (in debug or release):

❯ cargo build --release
   Compiling typenum v1.10.0
   Compiling semver-parser v0.7.0
   Compiling proc-macro2 v0.4.30
   Compiling unicode-xid v0.1.0
   Compiling rand_core v0.4.0
   Compiling syn v0.15.41
   Compiling stable_deref_trait v1.1.1
   Compiling cortex-m-rt v0.6.9
   Compiling vcell v0.1.0
   Compiling cortex-m v0.6.0
   Compiling stm32f3 v0.7.1
   Compiling r0 v0.2.2
   Compiling cortex-m-semihosting v0.3.3
   Compiling test v0.1.0 (/home/leshow/dev/embedded/test)
   Compiling panic-halt v0.2.0
   Compiling volatile-register v0.2.0
   Compiling rand_core v0.3.1
   Compiling rand v0.5.6
   Compiling semver v0.9.0
   Compiling generic-array v0.12.3
   Compiling rustc_version v0.2.3
   Compiling as-slice v0.1.0
   Compiling bare-metal v0.2.4
   Compiling aligned v0.3.1
   Compiling quote v0.6.13
   Compiling cortex-m-rt-macros v0.1.5
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/home/leshow/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/deps/test-1090b9e1da14b251.test.biugehj6-cgu.0.rcgu.o" "-o" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/deps/test-1090b9e1da14b251" "--gc-sections" "-L" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/deps" "-L" "/home/leshow/dev/embedded/test/target/release/deps" "-L" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/build/test-bd5b373cb2319a3a/out" "-L" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/build/cortex-m-5aa8e37429c9abc2/out" "-L" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/build/cortex-m-rt-3a1a97e3c2d417dd/out" "-L" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/build/cortex-m-semihosting-35622e2bd8b57563/out" "-L" "/home/leshow/dev/embedded/test/target/thumbv7em-none-eabihf/release/build/stm32f3-fd1a3010711a7fc0/out" "-L" "/home/leshow/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/tmp/rustcs88vjN/libcortex_m_rt-880bf24c42db6019.rlib" "/tmp/rustcs88vjN/libcortex_m-b41d19b44405705d.rlib" "--start-group" "--end-group" "/home/leshow/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-d51751fd2e6fcbd1.rlib" "-Tlink.x" "-Bdynamic"
  = note: rust-lld: error: 
          ERROR(cortex-m-rt): The interrupt vectors are missing.
          Possible solutions, from most likely to less likely:
          - Link to a svd2rust generated device crate
          - Disable the 'device' feature of cortex-m-rt to build a generic application (a dependency
          may be enabling it)
          - Supply the interrupt handlers yourself. Check the documentation for details.

If I follow the advice in config and also uncomment:

"-C", "linker=arm-none-eabi-ld"

I get an error with that linker:

= note: arm-none-eabi-ld: 
          ERROR(cortex-m-rt): The interrupt vectors are missing.

error compiling compiler_builtins

Hi I am trying to compile the hello example. But do not have any success. Here is the error message:

xargo build RUST_BACKTRACE=1 --verbose --target=thumbv7em-none-eabi --example hello
+ "rustc" "--print" "sysroot"
+ "rustc" "--print" "target-list"
+ RUSTFLAGS="-C link-arg=-Wl,-Tlink.x -C link-arg=-nostartfiles --sysroot /home/dimmiz/.xargo -Z force-unstable-if-unmarked"
+ "cargo" "build" "--release" "--manifest-path" "/tmp/xargo.8O2cHvoU1pyZ/Cargo.toml" "--target" "thumbv7em-none-eabi" "-v" "-p" "core"
   Compiling core v0.0.0 (file:///home/dimmiz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore)
     Running `rustc --crate-name core /home/dimmiz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C codegen-units=1 -C debuginfo=2 -C metadata=534dd594f582d058 -C extra-filename=-534dd594f582d058 --out-dir /tmp/xargo.8O2cHvoU1pyZ/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/tmp/xargo.8O2cHvoU1pyZ/target/thumbv7em-none-eabi/release/deps -L dependency=/tmp/xargo.8O2cHvoU1pyZ/target/release/deps -C link-arg=-Wl,-Tlink.x -C link-arg=-nostartfiles --sysroot /home/dimmiz/.xargo -Z force-unstable-if-unmarked`
    Finished release [optimized + debuginfo] target(s) in 1m 26s
+ RUSTFLAGS="-C link-arg=-Wl,-Tlink.x -C link-arg=-nostartfiles --sysroot /home/dimmiz/.xargo -Z force-unstable-if-unmarked"
+ "cargo" "build" "--release" "--manifest-path" "/tmp/xargo.jNfyOXaC42La/Cargo.toml" "--target" "thumbv7em-none-eabi" "-v" "-p" "compiler_builtins"
   Compiling compiler_builtins v0.1.0 (file:///home/dimmiz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins)
     Running `rustc --crate-name build_script_build /home/dimmiz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins/build.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C codegen-units=1 -C debuginfo=2 --cfg 'feature="compiler-builtins"' --cfg 'feature="default"' --cfg 'feature="mem"' -C metadata=e72572c230ee5f0c -C extra-filename=-e72572c230ee5f0c --out-dir /tmp/xargo.jNfyOXaC42La/target/release/build/compiler_builtins-e72572c230ee5f0c -L dependency=/tmp/xargo.jNfyOXaC42La/target/release/deps`
     Running `/tmp/xargo.jNfyOXaC42La/target/release/build/compiler_builtins-e72572c230ee5f0c/build-script-build`
     Running `rustc --crate-name compiler_builtins /home/dimmiz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C codegen-units=1 -C debuginfo=2 --cfg 'feature="compiler-builtins"' --cfg 'feature="default"' --cfg 'feature="mem"' -C metadata=0337e5cfae85ac18 -C extra-filename=-0337e5cfae85ac18 --out-dir /tmp/xargo.jNfyOXaC42La/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/tmp/xargo.jNfyOXaC42La/target/thumbv7em-none-eabi/release/deps -L dependency=/tmp/xargo.jNfyOXaC42La/target/release/deps -C link-arg=-Wl,-Tlink.x -C link-arg=-nostartfiles --sysroot /home/dimmiz/.xargo -Z force-unstable-if-unmarked --cfg thumb`
LLVM ERROR: Unexpected anonymous function when writing summary
error: Could not compile `compiler_builtins`.

Caused by:
  process didn't exit successfully: `rustc --crate-name compiler_builtins /home/dimmiz/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C codegen-units=1 -C debuginfo=2 --cfg feature="compiler-builtins" --cfg feature="default" --cfg feature="mem" -C metadata=0337e5cfae85ac18 -C extra-filename=-0337e5cfae85ac18 --out-dir /tmp/xargo.jNfyOXaC42La/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/tmp/xargo.jNfyOXaC42La/target/thumbv7em-none-eabi/release/deps -L dependency=/tmp/xargo.jNfyOXaC42La/target/release/deps -C link-arg=-Wl,-Tlink.x -C link-arg=-nostartfiles --sysroot /home/dimmiz/.xargo -Z force-unstable-if-unmarked --cfg thumb` (exit code: 1)
error: `"cargo" "build" "--release" "--manifest-path" "/tmp/xargo.jNfyOXaC42La/Cargo.toml" "--target" "thumbv7em-none-eabi" "-v" "-p" "compiler_builtins"` failed with exit code: Some(101)
note: run with `RUST_BACKTRACE=1` for a backtrace

os: Manjaro
rust: nightly-x86_64-unknown-linux-gnu
xargo: 0.3.12
cargo: 1.28.0-nightly (c3b09c968 2018-05-27)

Any idea what's going wrong?

Debug have some problems "unknown command: `arm` "

Os: win10
toolchain: stable-x86_64-pc-windows-msvc

config.toml

[target.thumbv7m-none-eabi]
# uncomment this to make `cargo run` execute programs on QEMU
runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel"

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
# uncomment ONE of these three option to make `cargo run` start a GDB session
# which option to pick depends on your system
 runner = "arm-none-eabi-gdb -q -x openocd.gdb"
# runner = "gdb-multiarch -q -x openocd.gdb"
# runner = "gdb -q -x openocd.gdb"

rustflags = [
  # This is needed if your flash or ram addresses are not aligned to 0x10000 in memory.x
  # See https://github.com/rust-embedded/cortex-m-quickstart/pull/95
  "-C", "link-arg=--nmagic",

  # LLD (shipped with the Rust toolchain) is used as the default linker
  "-C", "link-arg=-Tlink.x",

  # if you run into problems with LLD switch to the GNU linker by commenting out
  # this line
  # "-C", "linker=arm-none-eabi-ld",

  # if you need to link to pre-compiled C libraries provided by a C toolchain
  # use GCC as the linker by commenting out both lines above and then
  # uncommenting the three lines below
  # "-C", "linker=arm-none-eabi-gcc",
  # "-C", "link-arg=-Wl,-Tlink.x",
  # "-C", "link-arg=-nostartfiles",
]

[build]
# Pick ONE of these compilation targets
# target = "thumbv6m-none-eabi"        # Cortex-M0 and Cortex-M0+
target = "thumbv7m-none-eabi"        # Cortex-M3
# target = "thumbv7em-none-eabi"       # Cortex-M4 and Cortex-M7 (no FPU)
# target = "thumbv7em-none-eabihf"     # Cortex-M4F and Cortex-M7F (with FPU)
# target = "thumbv8m.base-none-eabi"   # Cortex-M23
# target = "thumbv8m.main-none-eabi"   # Cortex-M33 (no FPU)
# target = "thumbv8m.main-none-eabihf" # Cortex-M33 (with FPU)

I follow embedded book https://doc.rust-lang.org/stable/embedded-book/start/qemu.html
cargo build success, but i want to dbg, i use arm-none-eabi-gdb -q -x openocd.gdb

warning: No executable has been specified and target does not support                                           
determining executable automatically.  Try using the "file" command. 
0x00000464 in ?? ()                                                  
No symbol table is loaded.  Use the "file" command.                                                    
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
No symbol table is loaded.  Use the "file" command.                                                    
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
No symbol table is loaded.  Use the "file" command.                                                    
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
No symbol table is loaded.  Use the "file" command.                                                    
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
unknown command: 'arm'
.\openocd.gdb:37: Error in sourced command file:
No executable file specified.
Use the "file" or "exec-file" command.


GDB Load Failed Due to Invalid memory.x Flash Layout

Description

In the Hardware > Configuring section of the Rust Embedded Book, the FLASH : ORIGIN value is set to 0x08000000. However in the memory.x file, the value is set to 0x00000000.

FLASH : ORIGIN = 0x00000000, LENGTH = 256K

This is a very subtle difference but leads to the following error:

$ arm-none-eabi-gdb -q target/thumbv7em-none-eabihf/debug/examples/hello        
Reading symbols from target/thumbv7em-none-eabihf/debug/examples/hello...
(gdb) target remote :3333
Remote debugging using :3333
cortex_m_semihosting::export::hstdout_fmt (args=...) at /Users/martinomburajr/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-semihosting-0.3.7/src/export.rs:44
44	    interrupt::free(|_| unsafe {
(gdb) load
Loading section .vector_table, size 0x400 lma 0x0
Loading section .text, size 0x1134 lma 0x400
Load failed

After changing the value to FLASH : ORIGIN = 0x08000000, LENGTH = 256 the program works as expected.

This was pointed out in a Reddit Post last year.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.