Giter Site home page Giter Site logo

probe-rs / probe-rs Goto Github PK

View Code? Open in Web Editor NEW
1.5K 17.0 300.0 25.02 MB

A debugging toolset and library for debugging embedded ARM and RISC-V targets on a separate host

Home Page: https://probe.rs

License: Apache License 2.0

Rust 99.98% Shell 0.01% Assembly 0.01% Dockerfile 0.01%
arm debug rust coresight probe-rs arm-cores daplink debug-probes jlink stlink

probe-rs's Introduction

probe-rs

a modern, embedded debugging toolkit, written in Rust

crates.io documentation Actions Status chat

The goal of this library is to provide a toolset to interact with a variety of embedded MCUs and debug probes.

Similar projects like OpenOCD, PyOCD, Segger Toolset, ST Tooling, etc. exist. They all implement the GDB protocol and their own protocol on top of it to enable GDB to communicate with the debug probe. Only Segger provides a closed source DLL which you can use for talking to the JLink.

This project gets rid of the GDB layer and provides a direct interface to the debug probe, which then enables other software to use its debug functionality.

The end goal of this project is to have a complete library toolset to enable other tools to communicate with embedded targets.

Functionality

As of version 0.10.0 this library can

  • connect to a DAPLink, STLink or JLink
  • talk to ARM and Risc-V cores via SWD or JTAG
  • read and write arbitrary memory of the target
  • halt, run, step, breakpoint and much more the core
  • download ELF, BIN and IHEX binaries using standard CMSIS-Pack flash algorithms to ARM cores
  • provide debug information about the target state (stacktrace, stackframe, etc.)

To see what new functionality was added have a look at the CHANGELOG

Support

If you think probe-rs makes your embedded journey more enjoyable or even earns you money, please consider supporting the project on Github Sponsors for better support and more features.

Tools

In addition to being a library, probe-rs also includes a suite of tools which can be used for flashing and debugging.

Installation

The recommended way to install the tools is to download a precompiled version, using one of the methods below. See https://probe.rs/docs/getting-started/installation/ for a more detailed guide.

Using a shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/probe-rs/probe-rs/releases/latest/download/probe-rs-installer.sh | sh

Using a powershell script

irm https://github.com/probe-rs/probe-rs/releases/latest/download/probe-rs-installer.ps1 | iex

Using cargo-binstall

cargo binstall probe-rs

See https://github.com/cargo-bins/cargo-binstall for more information.

From source

The tools can also be installed from source. After installing the necessary prerequisites, the latest released version can be installed using cargo install:

cargo install probe-rs --locked --features cli

This will compile the tools and place them into the cargo bin directory. See the Cargo book for details.

cargo-flash

The cargo-flash utility can be used as a cargo subcommand to download a compiled Rust program onto a target device. It can also be used to download arbitrary ELF files that might come out of a C/C++ compiler. Have a look at cargo-flash for more information.

cargo-embed

If you are looking for a more extended debugging experience, please have a look at cargo-embed which provides support for GDB, RTT, and config files.

Editors and IDEs

We have implemented the Microsoft Debug Adapter Protocol (DAP). This makes embedded debugging via probe-rs available in modern code editors implementing the standard, such as VSCode. The DAP website includes a list of editors and IDEs which support DAP.

VSCode

The probe-rs website includes VSCode configuration instructions.

Usage Examples

Halting the attached chip

use probe_rs::{Permissions, Probe};

fn main() -> Result<(), probe_rs::Error> {
    // Get a list of all available debug probes.
    let probes = Probe::list_all();

    // Use the first probe found.
    let probe = probes[0].open()?;

    // Attach to a chip.
    let mut session = probe.attach("nRF52840_xxAA", Permissions::default())?;

    // Select a core.
    let mut core = session.core(0)?;

    // Halt the attached core.
    core.halt(std::time::Duration::from_millis(300))?;

    Ok(())
}

Reading from RAM

use probe_rs::{MemoryInterface, Permissions, Session};

fn main() -> Result<(), probe_rs::Error> {
    // Attach to a chip.
    let mut session = Session::auto_attach("nRF52840_xxAA", Permissions::default())?;

    // Select a core.
    let mut core = session.core(0)?;

    // Read a block of 50 32 bit words.
    let mut buff = [0u32; 50];
    core.read_32(0x2000_0000, &mut buff)?;

    // Read a single 32 bit word.
    let word = core.read_word_32(0x2000_0000)?;

    // Writing is just as simple.
    let buff = [0u32; 50];
    core.write_32(0x2000_0000, &buff)?;

    // of course we can also write 8bit words.
    let buff = [0u8; 50];
    core.write_8(0x2000_0000, &buff)?;

    Ok(())
}

FAQ

I need help!

Don't hesitate to file an issue, ask questions on Matrix, or contact @Yatekii via e-mail.

There is also a trouble-shooting section on the project page.

How can I help?

Please have a look at the issues or open one if you feel that something is needed.

Any contributions are very welcome!

Also have a look at CONTRIBUTING.md.

Our company needs feature X and would pay for its development

Please reach out to @Yatekii

Building

Building requires Rust and Cargo which can be installed using rustup. On Linux these can be installed with your package manager:

# Ubuntu
> sudo apt install -y libudev-dev

# Fedora
> sudo dnf install -y libudev-devel

Adding Targets

Target files are generated using target-gen from CMSIS packs provided here. Generated files are then placed in probe-rs/targets for inclusion in the probe-rs project.

Writing new flash algorithms

If there is no CMSIS-Pack with a flash algorithm available, it is necessary to write a target definition and a flash algorithm by oneself. You can use our template for writing an algorithm. Please follow the instructions in the README.md in that repo.

Acknowledgements

In early stages of this library, we profited invaluably from the pyOCD code to understand how flashing works. Also it's always a good reference to cross check how ARM specific things work. So, a big thank you to the team behind pyOCD!

License

Licensed under either of

Contributing

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.

probe-rs's People

Contributors

adamgreig avatar benmkw avatar bjoernq avatar bors[bot] avatar bugadani avatar dbrgn avatar dependabot-preview[bot] avatar dependabot[bot] avatar diondokter avatar dirbaio avatar disasm avatar hannobraun avatar hargonix avatar jacobrosenthal avatar jannic avatar jonas-schievink avatar mabezdev avatar noppej avatar probe-rs-bot avatar renovate[bot] avatar rnestler avatar ruabmbua avatar ryan-summers avatar thalesfragoso avatar thefaxman avatar therealprof avatar tiwalun avatar tmplt avatar urhengulas avatar yatekii 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

probe-rs's Issues

Real examples

We need 1 or 2 examples explaining how to use the library.

E.g. downloading a program and chip identification.

Automatically select probe

If only a single probe is connected, it might make sense to automatically select it for the cli
command.

Create a nice API for creating a new session for a lib user

Is your feature request related to a problem? Please describe.
Currently we have round about 4 to 5 different implementations for autoselecting a probe and creating a session. This is bad. The user doesn't really know how to open a session and takes quite some time to understand how.

Describe the solution you'd like
We could implemenet a method which could be Session::create(..) which takes the minimum required arguments to get a running session.

Maybe we could also employ the Builder pattern to make this process a little more configurable.

Describe alternatives you've considered
The only real alternatives are to leave the entire Session creation to the user which is tedious to use.

Detect when binary is for the wrong architecture

Currently, cargo-flash will try to flash binaries for any architectures.

Based on the cargo information, we should be able to detect if the user tries to flash a binary compiled for an unsupported architecture, and show an error message.

Implement more GDB stubs and improve overall features/stability

We need to implement more GDB stubs.

  • step (buggy)
  • step in (not implemented)
  • start (not implemented)
  • mon reset (not implemented)
  • next (not implemented)
  • semihosting
  • Error out on invalid "monitor" commands, display help
  • load

Bugs

  • High CPU usage after connection droped due to endless reads
  • --target parsing at wrong place
  • Reply contains invalid hex digit 84 (possibly due to T in reply packet?)

Features

  • Add --gdb to cargo flash

Make the spinners for the progress bars spin.

The progress bar spinners in #92 do not really spin yet. This is not breaking but it would be cool to see that something is ongoing and that it's not stuck.

I couldn't figure out how to make the library work ..

ST-Link v2-1 is not supported

Describe the bug

When connecting an ST-Link v2.1 (ID 0483:374b STMicroelectronics ST-LINK/V2.1) and trying to read the info it will lock up.

To Reproduce

$ target/debug/probe-rs-cli list
The following devices were found:
[0]: STLink V2-1 (VID: 1155, PID: 14155, STLink)

$ target/debug/probe-rs-cli info
DP info: 0x2ba01477

Available Access Ports:
IDR {
    REVISION: 0x2,
    DESIGNER: 0x23b,
    CLASS: MEMAP,
    _RES0: 0x0,
    VARIANT: 0x1,
    TYPE: AMBA_AHB3,
}
$ target/debug/probe-rs-cli info
Error processing command: UnknownError

Expected behavior
It should work 😉

Desktop (please complete the following information):

  • Linux (Arch)

Additional context
Add any other context about the problem here.

Using the nRF52840 target with the CMSIS-DAP by accident will panic

Describe the bug
When you attach a CMSIS-DAP probe andtry to flash an ELF binary with --chip nrf52840, an assertion will be triggered:

yatekii@arcturo:~/repos/probe-rs/nrf52-hal/boards/nRF52840-DK$ cargo flash --release --chip nrf52840 --example blinky --disable-progressbars
    Finished release [optimized + debuginfo] target(s) in 0.02s
    Flashing /home/yatekii/repos/probe-rs/nrf52-hal/target/thumbv7em-none-eabihf/release/examples/blinky
 WARN  probe_rs::config::registry > Found chip nRF52840_xxAA which matches given partial name nrf52840. Consider specifying it's full name.
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `1`', /home/yatekii/repos/probe-rs/probe-rs/probe-rs/src/probe/daplink/mod.rs:377:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior
We should
a) remove all assertions as well as panics. panics are not properly catchable and should really not be part of our lib as it will always crash the users program, which is not preferable. Imagine your entire IDE crashing because flashing failed. Great stuff.
b) We should just handle this response properly. We need to investigate what the actual answer of DAP is here. I don't know why the response is 4 bytes. I was convinced this is always 1 byte. Even if it is expected to be 1 byte, we should not panic if it's more.

Desktop (please complete the following information):

  • Linux (Ubuntu, 19.10)

Code cleanup

Fix:

  • Formatting
  • Dead code
  • Unused variables
  • Clippy hints

[0.6.2] nRF52840_xxAA: erase_sector fails with error code 1

Describe the bug

I get "erase_sector fails with error code 1" from both cargo-flash (tool) and probe_rs::flashing::download_file (library). I've tested with these combinations of probes: (CMSIS-DAP + nRF52840) and (J-Link + nRF52840).

To Reproduce

The ELF I'm using is basically what you get from compiling the snippet with opt-level = 'z':

#[cortex_m_rt::entry]
fn main() -> ! {
    loop { asm::nop() }
}
$ cargo flash --chip nrf52840
INFO probe_rs::flashing::download > Found 2 loadable sections:
INFO probe_rs::flashing::download >     .vector_table at 00000000 (1024 byte0)
INFO probe_rs::flashing::download >     .text at 00000400 (112 byte0)
INFO probe_rs::flashing::flasher  > Erasing sector at address 0x00000000
INFO probe_rs::flashing::flasher  > Done erasing sector. Result is 1. This took 20.939951ms
Error failed to flash app: The execution of 'erase_sector' failed with code 1
let probes = Probe::list_all();
let probe = probes[0].open()?;
let sess = probe.attach("nRF52840_xxAA")?;
let core = sess.attach_to_core(0)?;
flashing::download_file(&sess, path, Format::Elf)?;

Expected behavior

I expect both versions to be able to flash the device. OpenOCD is able to program the binary (tested both a nop loop and a blinky program):

$ openocd -f interface/cmsis-dap.cfg -f target/nrf52.cfg
(..)

$ telnet localhost 4444
> program path/to/elf
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000104c msp: 0x20040000
** Programming Started **
nRF52840-xxAA(build code: C0) 1024kB Flash, 256kB RAM
Flash protection of this nRF device is not supported
Adding extra erase range, 0x00000470 .. 0x00000fff
** Programming Finished **

Stacktrace

See logs in the STR section (I can provide trace logs as well)

Desktop

  • Arch Linux x86_64
  • cargo-flash 0.6.0
  • probe_rs 0.6.2

Additional context

AFAIK the device has no way to set write protection for Flash (it can set write protection for the "User Configuration" section but that's at a different address: 0x1000_1000). Both cargo flash and probe_rs::flashing also fail after OpenOCD flashed a binary (I tested this in case OpenOCD did remove write protection).

Any other info I can provide to help debug this?

Support ST chip identification

ST has a proprietary method to identify chips, based on the DBGMCU_IDCODE register. This is described in the reference manuals of the chips.

We should support this to properly identify ST chips.

See #113 for more discussion of this.

Issue connecting to EFR32MG21 Cortex M33 chip on v0.5.0 using STLink V2

Describe the bug
probe-rs is unable to talk to the AP (CSW register) when using version 0.5.0
With version 0.4.0 it seems to correctly show the information for the chip. I have not attempted actual flashing yet.
(Note, the goal is of course to run it with cargo-flash, but I'm using probe-rs-cli to verify the target yaml and proper connection to the chip)

To Reproduce
Run probe-rs-cli info with an EFR32MG21 connected with an ST-Link.
This also happens with any other commands, but info is nice and simple.

Expected behavior
That it would show me info about the chip.

Stacktrace
probe-rs-cli-0.4.0.log
probe-rs-cli-0.5.0.log

Desktop (please complete the following information):
Ubuntu

Additional context
I've verified Openocd is able to connect and talk to the chip (although it lacks specific support for the part, so no flashing).

`cargo flash` tries to flash even when the build fails

When running cargo flash on code containing a compilation error, Cargo will print the error, but cargo flash still attempts to flash the binary, which is now either outdated or doesn't exist.

It should check the status code of Cargo and only proceed to the Flashing <file> step if it's 0.

Double attach is possibly bad?

The problem

In most cases we perform a double attach.

When the user creates a probe, we call attach on the probe: https://github.com/probe-rs/probe-rs/blob/master/probe-rs/src/probe/mod.rs#L123
And when the user attaches to a target, we call attach on the probe again: https://github.com/probe-rs/probe-rs/blob/master/probe-rs/src/probe/mod.rs#L210

This effect can be seen here: https://github.com/probe-rs/cargo-flash/blob/master/src/main.rs#L234-L268.

The effect is possibly bad because if a probe for example does not support SWD and the default is SWD and it tries to use that, hell breaks loose.

Solutions

If we remove the first one, it is not guaranteed that when the user operates on the probe, for example via DapAccess: https://github.com/probe-rs/probe-rs/blob/master/probe-rs/src/probe/mod.rs#L250, that the probe is actually attached to the chip.

If we remove the second one, all the settings like the protocol etc do not get applied.

I see 2 solutions: a) use a typestate to track whether it's attached or not or b) use an internal bool and attach if the probe is not attached.

ping: @Tiwalun @Disasm

Flash an external ELF binary ?

Hello,

I want to put some Rust in my C, and I want to know if probe-rs will be capable of flashing the resulting binary (rust static lib linked with C code).
I digged in the code, and it seems it currently expect to flash a file from the target directory, not a provided external file.

Thanks !

cargo flash docs not clear about "package"

I got excited seeing that the blackmagic probe is now getting some probe-rs support:

https://twitter.com/yatekii/status/1211121477250113542

And tried it out on my NRF52840 dongle, but I'm struggling a bit with blinky from the README.md:

$ cargo flash --release --chip nRF52840 --example gpio_hal_blinky
missing field `package`
$ cargo flash --package=probe --release --chip nRF52840 --example gpio_hal_blinky
missing field `package`
$ cargo flash --release --chip nRF52840 --target thumbv6m-none-eabi --example gpio_hal_blinky --package=stlink
missing field `package`
$ cargo flash --package stlink --release --chip nRF52840 --example gpio_hal_blinky
missing field `package`

For more context, I'm using an STLink dongle reprogrammed with blackmagic.bin and it works well identifying the target on bare gdb:

(gdb) monitor
Black Magic Probe (Firmware v1.6.1-381-g8a07f44) (Hardware Version 1)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

(gdb) monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      Nordic nRF52 M3/M4
 2      Nordic nRF52 Access Port

(gdb) mon read deviceinfo
Part:		NRF52840
Variant:	AAC0
Package:	QIxx
Ram:		256K
Flash:		1024K

But it would be epic to cargo flash my firmware right away :)

Support RISCV chips with only single program buffer.

The current RISCV debug implementation assumes that all targets have at least two program buffer slots. The debug specification also allows for implementations with only a single program buffer slot, and an implict ebreak at the end.

To support this, the number of program buffer slots has to be checked, and the usage of the slots has to be adapted.

See #144

Open issues for planned features?

I’d like to contribute but don’t really know what needs doing, I don’t suppose you could open some issues for missing features/bug fixes?

Proper docs

Write docs for all the library components.
Especially CoreSight specific things have to be documented properly.
This includes:

  • AP functionality
  • DP functionality
  • MemoryAP registers/functionality
  • ROM table functionality
  • Device discovery
  • MemoryFlasher

Panic on `probe.attach("somemcu")` when no MCU is connected

Describe the bug
Panic on probe.attach("somemcu") when no MCU is connected.

Panic message: thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 18446744073709551615', /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/slice/mod.rs:2842:1

To Reproduce
Steps to reproduce the behavior:

  1. Run probe.attach("somemcu") with no MCU connected

Expected behavior
The return of attach should have been an error

Make autodetection more reliable & precise

Does the nRF51822_xxAB have the same part number as the xxAC variant?

Originally posted by @Tiwalun in #106

Known issues

  • Multiple chips could match, make sure we get the right one
  • Do different variants have the same part number and only differ in memory, or do they also have different part numbers?
  • Either way we should find out & potentially implement memory config readout from the ROMtables.

zetz support / reusability as C library

Hi,

i was wondering what's needed to use this outside of rust,
specifically in zetz , but other non-rust projects such as IDEs could benefit

the library first approach is great, and would make this very reusable. since rust has its own incompatible ABI unfortunately to make it work outside of rust, you'd have to add an extra standard ABI layer. Would that be something you'd be willing to maintain on top?

JLink probe interface always uses SWD for ARM targets

When attaching without a specified target, probe-rs tries to automatically determine the connected chip.

Actual Behaviour

When this is done with a connected J-Link, it will first try to detect a connected ARM chip. For this,
the DAPAccess trait is used. The implementation for J-Link uses SWD specific function. When these functions are used, the probe automatically tries to to switch to the SWD protocol. However, not all J-Links support this switch. If the connected probe does not support switching protocols (i.e. capability SELECT_IF is missing), this leads to an error. This error means that auto-detection fails, and the connection procedure is aborted. The following error is shown, if the probe only supports JTAG:

Error processing command: An error with the usage of the probe occured: An error specific to a probe type occured: device is missing capabilities (SELECT_IF) for operation

Expected behaviour

If detecting an ARM chip fails, we should still try detecting a RISCV chip. Also, if auto-detection fails, the error should clearly indicate this.

Can't read RAM with a STLINK-V3 probe

Describe the bug
Can't read RAM with a STLINK-V3 probe

To Reproduce
Steps to reproduce the behavior:

  1. let probe: Probe = probes[0].open();
  2. let session = probe.attach("stm32f401").unwrap();
  3. let mem = session.attach_to_memory(0).unwrap();
  4. mem.read32(0x2000_0000).unwrap();

Project: https://github.com/Disasm/stlink-probe-bug

Expected behavior
read32() should return Ok(_)

Stacktrace

Backtrace

Available probes: [STLink V3 (VID: 1155, PID: 14159, STLink)]
Probe opened
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ArchitectureSpecific(RegisterWriteError { address: 0, name: "CSW" })', src/main.rs:18:13
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::sys_common::backtrace::print
   4: std::panicking::default_hook::{{closure}}
   5: std::panicking::default_hook
   6: std::panicking::rust_panic_with_hook
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
  10: core::result::Result<T,E>::unwrap
             at /home/disasm/dev/rust/embedded/ports/rust-async/src/libcore/result.rs:1003
  11: stlink_probe_bug::main
             at src/main.rs:18
  12: std::rt::lang_start::{{closure}}
             at /home/disasm/dev/rust/embedded/ports/rust-async/src/libstd/rt.rs:67
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: std::panicking::try
  16: std::rt::lang_start_internal
  17: std::rt::lang_start
             at /home/disasm/dev/rust/embedded/ports/rust-async/src/libstd/rt.rs:67
  18: main
  19: __libc_start_main
  20: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Debug logs

 DEBUG jaylink > libusb 1.0.23.11397
 DEBUG jaylink > libusb has capability API: true
 DEBUG jaylink > libusb has HID access: true
 DEBUG jaylink > libusb has hotplug support: true
 DEBUG jaylink > libusb can detach kernel driver: true
Available probes: [STLink V3 (VID: 1155, PID: 14159, STLink)]
 DEBUG probe_rs::probe::stlink::usb_interface > Acquired libusb context.
 DEBUG probe_rs::probe::stlink::usb_interface > Aquired handle for probe
 DEBUG probe_rs::probe::stlink::usb_interface > Active config descriptor: ConfigDescriptor { bLength: 9, bDescriptorType: 2, wTotalLength: 151, bNumInterfaces: 5, bConfigurationValue: 1, iConfiguration: 4, bmAttributes: 128, bMaxPower: 250, extra: None }
 DEBUG probe_rs::probe::stlink::usb_interface > Device descriptor: DeviceDescriptor { bLength: 18, bDescriptorType: 1, bcdUSB: 512, bDeviceClass: 239, bDeviceSubClass: 2, bDeviceProtocol: 1, bMaxPacketSize: 64, idVendor: 1155, idProduct: 14159, bcdDevice: 256, iManufacturer: 1, iProduct: 2, iSerialNumber: 3, bNumConfigurations: 1 }
 DEBUG probe_rs::probe::stlink::usb_interface > Claimed interface 0 of USB device.
 DEBUG probe_rs::probe::stlink::usb_interface > Succesfully attached to STLink.
 DEBUG probe_rs::probe::stlink                > Initializing STLink...
 DEBUG probe_rs::probe::stlink                > Current device mode: Jtag
 DEBUG probe_rs::probe::stlink                > STLink version: (3, 4)
 DEBUG probe_rs::probe::stlink                > attach(Swd)
 DEBUG probe_rs::probe::stlink                > Current device mode: Jtag
 DEBUG probe_rs::probe::stlink                > Switching protocol to SWD
 DEBUG probe_rs::probe::stlink                > Successfully initialized SWD.
Probe opened
 DEBUG probe_rs::probe::stlink                > attach(Swd)
 DEBUG probe_rs::probe::stlink                > Current device mode: Jtag
 DEBUG probe_rs::probe::stlink                > Switching protocol to SWD
 DEBUG probe_rs::probe::stlink                > Successfully initialized SWD.
 WARN  probe_rs::config::registry             > Found chip STM32F401CBUx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CBYx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CCUx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CCYx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CDUx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CDYx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CEUx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401CEYx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401RBTx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401RCTx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401RDTx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401RETx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VBHx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VBTx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VCHx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VCTx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VDHx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VDTx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VEHx which matches given partial name stm32f401. Consider specifying it's full name.
 WARN  probe_rs::config::registry             > Found chip STM32F401VETx which matches given partial name stm32f401. Consider specifying it's full name.
 DEBUG probe_rs::architecture::arm::communication_interface > Debug Port version: DPv1
 DEBUG probe_rs::architecture::arm::communication_interface > Reading DP register DPIDR
 DEBUG probe_rs::architecture::arm::communication_interface > Read    DP register DPIDR, value=0x2ba01477
 DEBUG probe_rs::architecture::arm::communication_interface > DebugPort ID:  DebugPortId {
    revision: 0x2,
    part_no: 0xba,
    version: DPv1,
    min_dp_support: NotImplemented,
    designer: JEP106Code({ cc: 0x04, id: 0x3b } => Some("ARM Ltd")),
}
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register ABORT, value=0x0000003c
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register SELECT, value=0x00000000
 DEBUG probe_rs::architecture::arm::communication_interface > Requesting debug power
 DEBUG probe_rs::architecture::arm::communication_interface > Writing DP register CTRL/STAT, value=0x50000000
 DEBUG probe_rs::architecture::arm::communication_interface > Reading DP register CTRL/STAT
 DEBUG probe_rs::architecture::arm::communication_interface > Read    DP register CTRL/STAT, value=0xf0000040
 DEBUG probe_rs::architecture::arm::communication_interface > Writing register CSW, value=0x63000012
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ArchitectureSpecific(RegisterWriteError { address: 0, name: "CSW" })', src/main.rs:18:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 DEBUG probe_rs::probe::stlink                              > Current device mode: Jtag

Desktop (please complete the following information):

  • Linux (ArchLinux rolling release)

Additional context
Hardware: STLINK-V3SET
Target board: F401-pill
Connection: SWDIO & SWCLK only

(Better) support for cheap ST-link clones

As requested in https://github.com/probe-rs/cargo-flash/issues/20, here are the details about my setup.

I'm using an ST-link clone from Aliexpress, as shown here (no modifications applied). The USB interface registers as

Bus 001 Device 008: ID 0483:3748 STMicroelectronics ST-LINK/V2

Flashing works but I have to select the correct chip (in my case, stm32f429vgtx) and set the speed argument to 1800 kHz, and I get the following output:

    Flashing /home/gbr/devel/stm_display/firmware/target/thumbv7em-none-eabihf/release/display_firmware
        WARN probe_rs::flashing::flasher > Error while waiting for core halted: An error with the usage of the probe occured: Operation timed out.
[... same warning ca. 20 times]
        WARN probe_rs::flashing::flasher > Error while waiting for core halted: An error with the usage of the probe occured: Operation timed out.
     Erasing sectors ✔ [00:00:02] [###########] 128.00KB/128.00KB @  44.14KB/s (eta 0s )
 Programming pages   ✔ [00:00:07] [###########] 128.00KB/128.00KB @  13.10KB/s (eta 0s )

When flashing with OpenOCD/gdb, it seems to recognize that the speed needs to be reduced,
the output is as follows:

adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.225347
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20016419
Info : flash size = 1024kbytes
Info : Single Bank 1024 kiB STM32F42x/43x/469/479 found
undefined debug reason 7 - target needs reset
semihosting is enabled
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08006586 msp: 0x10010000, semihosting
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
Info : Padding image section 0 with 4 bytes
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000046 msp: 0x10010000, semihosting
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08006586 msp: 0x10010000, semihosting

The OpenOCD config is:

source [find interface/stlink-v2.cfg]
transport select hla_swd
source [find target/stm32f4x.cfg]

It is also much quicker (3.5s) compared to cargo-flash which takes about 11s.

STLink-V3 SWD speeds missing

Hi,
The STLink-V3 supports up to 24 MHz SWD, however the implementation only seems to go up to 4.6 MHz from recent additions.
Putting the issue here so it is not forgotten.

Extend & clean README.md

We need a proper README.md addressing the current state of the project, describing working features properly and informing about the project in general.

Support for the e-link32

Is your feature request related to a problem? Please describe.
I can't find any non Windows software that allows me to communicate with the e-link32 on the eval boards for my holtek chips.

Describe the solution you'd like
It would be pretty neat if probe.rs would have support for this debugger and maybe chips of holtek I'm using.

Describe alternatives you've considered
Using Windows and ARM Keil or other Windows tooling holtek provides seems to be the only way.

Additional context
I'd love to implement this myself however as I've never done anything related to this I am a little lost, I couldn't find any documentation etc. related to how the Holtek software actually talks to the e-link probe. If someone could tell me either how I should debug the software under Windows or can point me to some docs I oversaw I'd happily tackle this myself. In case there isn't any documentation I guess reverse engineering what their standalone tools are doing is the best way?

Chip erase will report a wrong total of bytes to be erased in the flashprogress

When one does a chip erase in the flash procedure, the progress report will report the number of sections the flash builder deemed necessary to be erased instead of the actual flash size.
This should be corrected such that it represents the total flash size.

Relevant line: https://github.com/probe-rs/probe-rs/blob/master/probe-rs/src/flashing/flasher.rs#L273

Maybe we need an argument, which tells that the entire chip will be erased so the user can report accordingly?

ping: @Tiwalun

Clear breakpoints when detaching

Currently, we do not clear HW breakpoints when detaching. We also do not check when
attaching what the current state of the HW breakpoint unit is.

We should:

  • Clear HW breakpoints when detaching
  • Check the state of the breakpoint unit when attaching

Determine information about debug module at initialisation

Information about the debug module should be determined once at startup, and stored.

Information that could be determined:

  • Number of triggers (for breakpoints)
  • Progbuf size
  • Number of debug modules
  • Support for direct system bus access
  • ...

Changes to the target description format.

The problem

Currently we use a YAML format for describing targets. This has certain limitations.
When I created the YAML description format, it was aimed at providing a basic, a litle more than proof of concept state, simple format to describe targets and how we can flash them.
Now we start to exceed its limits and we need to address certain changes that are required.
This issue is aimed at coordinating the changes to the system we make target descriptions with that are required to overcome those limitations and be fit for future functionality.

Current state

The current target descripion format is done in YAML. It is a leightweight format, independent of language, which was picked to enable everyone, even non-Rust folks, to patch or even write target descriptions.
Currently the target descriptions essentially hold a memory map, a list of flash algorithms and the core type, together with some metadata about the chip.
The flash algorithms are ARM ASM binary blobs represented in base64 strings contained in the yaml file.
Only single core chips are supported currently. The description only contains the type of core (M0, M4, etc).
The memory map is on a per target basis.

The deficiencies

Dualcore (or more) systems are currently not supported. For some targets this would be nice to have. This doesn't mean we need full dualcore support (for example the GDB doesn't have that yet), but we can still include all the properties we will need for flashing and later dualcore operations.

The format is not very flexible. To this point it has been non-ARM specific, even tho it originated from ARM specific CMSIS-Packs.

Proposed changes

  1. Make the core a list of cores instead of a single core. Make the list of cores a list of objects describing the core more than just by its name. The core info of each core should contain the AP and the DP the respective core has to use. CMSIS-Packs contain the numbers for multicore systems, so we can parse them easily.
  2. Add a memory map to each core instead of just one map to the target, such that only the memories a core can actually access are present on that core entry. There is many systems with an M0 and an M4 e.g. where only the M4 can access the flash because the M0 is in some security confinement and only meant as a coprocessor.
  3. Change the format. I don't think YAML is fit in the longer run.
    While we might be able to extend it for now, it does not mean that it will serve every purpose in the long run.
    My proposal here would be to use actual Rust. We can easily generate a code file with a struct definition in it which covers all the things the YAML covered.
    What this offers additionally tho: We can define traits which are meant to be implemented on targets. This way we can implement custom hooks for specific targets, let's say for unlocking. The implementations could be defined in different files, such that, when regenerating the targets from updated CMSIS-Packs (or similar for other architectures), the custom code wont be overridden.
    I would prefer not to use a scripting language here.
  • Because I love Rust and
  • Because I have the fear that a scripting language is not fit for this job to do right. If you don't think so, have a look at the low level PyOCD code. It is not obvious at all how the bits and bytes flow, because python doesn't really care about those on the low level. Many things are strings and such hacky solutions because Python doesn't have the right concept.
  • Using pure Rust spares us from having weird interfaces.
    This approach comes with a downside of course: The user cannot hotload any target descriptions. If we wanted to do this, we would need to compile the descriptions to WASM.

Conclusion

I think changes are necessary and I would like to discuss them before they are just done blindly and need more change later on (ofc this can still happen).
Please add your opinions and thoughts to this thread. I am very keen to hear them :)

Best,
Yatekii

Fails to flash using a GD-Link, a CMSIS-DAP debugger

Describe the bug
I tried to flash with a GD-Link debugger (CMSIS-DAP) connected, but error occurred.

To Reproduce
Steps to reproduce the behavior:

  1. Connect GD32VF103C-START board (with GD-Link) to the computer
  2. Clone https://github.com/gd32v-rust/gd32vf103-hal
  3. Execute cargo flash --example vf103c-start-blinky

Expected behavior
The program should be flashed and the LED light blinks.

Stacktrace
No stacktrace available

Desktop (please complete the following information):

  • macOS Catalina 10.15.3

Additional context
RUST_LOG=debug report:
zvCwSEKYSPtbjuwNlCbjxHTz

Full RUST_LOG=trace report:
https://paste.ubuntu.com/p/V5ygXJSqTz/

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.