Skip to content
This repository has been archived by the owner on Jan 30, 2024. It is now read-only.

Cannot flash to XMC4500 #386

Open
KRACK-BIT opened this issue Feb 27, 2023 · 6 comments
Open

Cannot flash to XMC4500 #386

KRACK-BIT opened this issue Feb 27, 2023 · 6 comments
Labels
status: needs info Requires more information to move forward topic: memory type: bug Something isn't working

Comments

@KRACK-BIT
Copy link

Cannot run probe-run on an XMC4500 microcontroller; memory ranges are apparently incorrect
I am currently trying to flash a very basic hello world program as a proof-of-concept for running on my microcontroller; however, this fails to run.

To Reproduce
Steps to reproduce the behavior:

Example

  1. Install dependencies (snippet from my dockerfile):
RUN apt install -y libusb-1.0-0-dev libudev-dev
RUN apt install -y libudev-dev
RUN sudo apt install -y acl less man-db nano
RUN cargo install cargo-generate cargo-binutils
RUN cargo install cargo-flash probe-rs probe-rs-cli probe-run

RUN rustup target add thumbv7em-none-eabihf
RUN rustup component add llvm-tools-preview
RUN rustup component add rustfmt
  1. Write example/hello.rs
//! Prints "Hello, world!" on the host console using semihosting

#![no_main]
#![no_std]

use panic_semihosting as _;

use cortex_m_rt::entry;
use cortex_m_semihosting::hprintln;

#[entry]
fn main() -> ! {
    hprintln!("Hello, world!");

    // exit QEMU
    // NOTE do not run this on hardware; it can corrupt OpenOCD state
    // debug::exit(debug::EXIT_SUCCESS);

    loop {}
}
  1. Run it with cargo run --example hello

Expected and observed behavior
I was expecting it to successfully execute and print hello world

Resulting behavior however was

root@996f111a2f2d:/workspaces/kybe-rs# cargo run --example hello
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `probe-run --chip XMC4500-F100x1024 target/thumbv7em-none-eabihf/debug/examples/hello`
Error: Error while flashing

Caused by:
    No flash memory contains the entire requested memory range 0x0c000000.. 0xc000400.

config.toml

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip XMC4500-F100x1024"


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",
]

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

Probe details

The following devices were found:
[0]: J-Link (J-Link) (VID: 1366, PID: 0101, Serial: 000551022083, JLink)

Operating System:
Docker Desktop on Windows (i.e. Linux VM on Windows); I've got USB pass-through set up, am doing everything within Linux, and it was working without issue when flashing with GDB, so should be working indistinguishable to a Linux box.

ELF file (attachment)
I am happy to upload this, but rn GitHub isn't letting me upload things which are not a specific file type; what is the recommended way of uploading ELF files here?

@Urhengulas Urhengulas added type: bug Something isn't working status: needs info Requires more information to move forward topic: memory labels Feb 27, 2023
@Urhengulas
Copy link
Member

Hi @KRACK-BIT,

Did you do all the steps listed in the README of our app-template (https://github.com/knurling-rs/app-template)? Which HAL did you specify (maybe share your Cargo.toml)?

Is there a specific reason you use cortex-m-semihosting and not defmt? I don't know how the semihosting works and if it is maybe causing the issue.

@KRACK-BIT
Copy link
Author

KRACK-BIT commented Feb 27, 2023

Hi @KRACK-BIT,

Did you do all the steps listed in the README of our app-template (https://github.com/knurling-rs/app-template)? Which HAL did you specify (maybe share your Cargo.toml)?

Is there a specific reason you use cortex-m-semihosting and not defmt? I don't know how the semihosting works and if it is maybe causing the issue.

Thanks for the reply @Urhengulas

I've gone through and switched my code to comply with the template; however, the code still does not work.

  • I am now complying with all steps from the app-template
  • My current HAL is xmc4500; I was also considering using xmc4-hal, but the cortex-m-rt version used by defmt-test conflicts with this.
  • I have switched over to using defmt, so I am no longer using semihosting

@KRACK-BIT
Copy link
Author

KRACK-BIT commented Feb 27, 2023

Moreover, even when I downgrade and switch to using xmc4-hal, it does not work:

Current Cargo.toml

[package]
authors = ["KRACKY <[email protected]>"]
name = "kybe-rs"
edition = "2021"
version = "0.1.0"

[lib]
harness = false

# needed for each integration test
[[test]]
name = "integration"
harness = false

[dependencies]
cortex-m = { version = "0.7", features = ["critical-section-single-core"] }
cortex-m-rt = "0.6"
# cortex-m-rt = "0.7"
# defmt = "0.2"
defmt = "0.3"
# defmt-rtt = "0.2"
defmt-rtt = "0.4"
# panic-probe = { version = "0.2", features = ["print-defmt"] }
panic-probe = { version = "0.3", features = ["print-defmt"] }
xmc4-hal = { version = "0.0.1", features = ["xmc4500"] }
# xmc4500 = "0.6.0"

# Rust crypto primities
sha3 = { version = "0.10.6", default-features = false }
kem = "0.2.0"
# hex-literal = "0.3.4"

# Uncomment for the allocator example.
# alloc-cortex-m = "0.4.0"

[dev-dependencies]
# defmt-test = "0.3"
# defmt-test = "0.2.3"

# [[bin]]
# name = "kybe-rs"
# test = false
# bench = false

# cargo build/run
[profile.dev]
codegen-units = 1
debug = 2
debug-assertions = true # <-
incremental = false
opt-level = 'z'         # <-
overflow-checks = true  # <-

# cargo test
[profile.test]
codegen-units = 1
debug = 2
debug-assertions = true # <-
incremental = false
opt-level = 3           # <-
overflow-checks = true  # <-

# cargo build/run --release
[profile.release]
codegen-units = 1
debug = 2
debug-assertions = false # <-
incremental = false
lto = 'fat'
opt-level = 3            # <-
overflow-checks = false  # <-

# cargo test --release
[profile.bench]
codegen-units = 1
debug = 2
debug-assertions = false # <-
incremental = false
lto = 'fat'
opt-level = 3            # <-
overflow-checks = false  # <-

# uncomment this to switch from the crates.io version of defmt to its git version
# check app-template's README for instructions
# [patch.crates-io]
# defmt = { git = "https://github.com/knurling-rs/defmt", rev = "use defmt version reported by `probe-run --version`" }
# defmt-rtt = { git = "https://github.com/knurling-rs/defmt", rev = "use defmt version reported by `probe-run --version`" }
# defmt-test = { git = "https://github.com/knurling-rs/defmt", rev = "use defmt version reported by `probe-run --version`" }
# panic-probe = { git = "https://github.com/knurling-rs/defmt", rev = "use defmt version reported by `probe-run --version`" }

@KRACK-BIT
Copy link
Author

KRACK-BIT commented Feb 27, 2023

@Urhengulas do you (or anyone who is reading this) know if there are any examples of XMC devices successfully using this template for probe-run? It claims to be officially supported by probe-run, but I can't find any articles or issues giving a successful example of it running

@Urhengulas
Copy link
Member

@Urhengulas do you (or anyone who is reading this) know if there are any examples of XMC devices successfully using this template for probe-run? It claims to be officially supported by probe-run, but I can't find any articles or issues giving a successful example of it running

I am not aware of any.

@Urhengulas
Copy link
Member

Maybe you can open an issue on one of the HALs and ask if they have experience?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: needs info Requires more information to move forward topic: memory type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants