Daisy development with the Rust language using probe-run

[obust]

Hello everyone,

I would like to program in Rust on the Daisy Seed but I am running into issues while flashing the code.

Here are the steps to reproduce:

1. Setup Rust development environment

# install rustc and cargo
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# install probe-run (with defmt)
cargo install \
    --git https://github.com/knurling-rs/probe-run \
    --branch main \
    --features defmt

# install cargo-generate (with defmt)
cargo install cargo-generate

# generate project template for embedded dev
cargo generate \
    --git https://github.com/knurling-rs/app-template \
    --branch main \
    --name daisy-seed

cd daisy-seed

2. Now there are a few thing to customize in the template for the STM32H750IBK6 chip

# .cargo/config.toml
# TODO(2) replace `$CHIP` with your chip's name (see `probe-run --list-chips` output)
runner = "probe-run --chip STM32H750IBKx --defmt"
# TODO(3) Adjust the compilation target.
target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)

# Cargo.toml
# TODO(4) enter your HAL here (cf https://crates.io/crates/stm32h7xx-hal)
stm32h7xx-hal = {version = "0.7.1", features = ["stm32h743v","rt"]}

# src/lib.rs
// TODO(5) adjust HAL import
use stm32h7xx_hal as _; // memory layout

# Add `memory.x` linker script for `cortex-m-rt`
curl https://raw.githubusercontent.com/stm32-rs/stm32h7xx-hal/master/memory.x > memory.x
# Uncomment the FLASH length corresponding to STM32H750xB
FLASH  : ORIGIN = 0x08000000, LENGTH = 128K

3. Finally, build and flash the test program with: cargo run --bin hello.

This gives me the following error:

     ...
     Running `probe-run --chip STM32H750IBKx --defmt target/thumbv7em-none-eabihf/debug/hello`
flashing program ..
[2020-09-05T11:20:15Z INFO  probe_run] opened probe
[2020-09-05T11:20:15Z INFO  probe_run] started session
[2020-09-05T11:20:15Z INFO  probe_rs::flashing::download] Found 4 loadable sections:
[2020-09-05T11:20:15Z INFO  probe_rs::flashing::download]     .vector_table at 08000000 (664 byte0)
[2020-09-05T11:20:15Z INFO  probe_rs::flashing::download]     .text at 08000298 (1792 byte0)
[2020-09-05T11:20:15Z INFO  probe_rs::flashing::download]     .rodata at 080009A0 (372 byte0)
[2020-09-05T11:20:15Z INFO  probe_rs::flashing::download]     .data at 20000000 (48 byte0)
[2020-09-05T11:20:15Z WARN  probe_rs::architecture::arm::core::m4] Reason for halt has changed, old reason was Halted(Unknown), new reason is Request
[2020-09-05T11:20:15Z WARN  probe_rs::architecture::arm::core::m4] Reason for halt has changed, old reason was Halted(Request), new reason is Exception
[2020-09-05T11:20:15Z ERROR probe_rs::flashing::flasher] Failed to verify flash algorithm. Data mismatch at address 0x30000200
[2020-09-05T11:20:15Z ERROR probe_rs::flashing::flasher] Original instruction: 0xe00abe00
[2020-09-05T11:20:15Z ERROR probe_rs::flashing::flasher] Readback instruction: 0x000000
[2020-09-05T11:20:15Z ERROR probe_rs::flashing::flasher] Original: [e00abe00, 62d780d, ..., 52002114, 0]
[2020-09-05T11:20:15Z ERROR probe_rs::flashing::flasher] Readback: [0, 0, 0, ..., 0, 0]
Error: Error while flashing

Caused by:
    The RAM contents did not match the expected contents after loading the flash algorithm.

Now I don’t know what to do to fix this issue.
I have looked at Electrosmith’s Arduino linker script but playing with the memory definitions did not give other outcome and I don’t understand much of the SECTIONS part…

I would appreciate if someone could help me debug this so that I can get to the fun part

Thank you in advance

NB:

• I use the STLINK-V3MINI as probe
• knurlings app-template: https://github.com/knurling-rs/app-template
• knurlings app-template setup with defmt: https://ferrous-systems.com/blog/defmt/

[antisvin]

The error from flasher occurs when it tries to verify that correct data was written to flash. But it mentions address 0x30000200. This belongs to D2 RAM region, not flash.

[obust]

Isn’t it fashing the flash algorithm to FLASH, then running it and checking RAM ?

Here is my linker script:

MEMORY
{
  /* https://github.com/stm32-rs/stm32h7xx-hal/blob/master/memory.x */
  /* FLASH and RAM are mandatory memory regions */

  /* STM32H750xB   */
  FLASH  : ORIGIN = 0x08000000, LENGTH = 128K

  /* DTCM  */
  RAM    : ORIGIN = 0x20000000, LENGTH = 128K

  /* AXISRAM */
  AXISRAM : ORIGIN = 0x24000000, LENGTH = 512K

  /* SRAM */
  SRAM1 : ORIGIN = 0x30000000, LENGTH = 128K
  SRAM2 : ORIGIN = 0x30020000, LENGTH = 128K
  SRAM3 : ORIGIN = 0x30040000, LENGTH = 32K
  SRAM4 : ORIGIN = 0x38000000, LENGTH = 64K

  /* Backup SRAM */
  BSRAM : ORIGIN = 0x38800000, LENGTH = 4K

  /* Instruction TCM */
  ITCM  : ORIGIN = 0x00000000, LENGTH = 64K
}

/* The location of the stack can be overridden using the
   `_stack_start` symbol.  Place the stack at the end of RAM */
_stack_start = ORIGIN(RAM) + LENGTH(RAM);

/* The location of the .text section can be overridden using the
   `_stext` symbol.  By default it will place after .vector_table */
/* _stext = ORIGIN(FLASH) + 0x40c; */

/* These sections are used for some of the examples */
SECTIONS {
  .axisram : ALIGN(8) {
    *(.axisram .axisram.*);
    . = ALIGN(8);
    } > AXISRAM
  /* The SRAM1 and SRAM2 section are commonly used as the stack and heap for the
     CM4 core in dualcore versions and should thus not be used in examples*/
  .sram3 (NOLOAD) : ALIGN(4) {
    *(.sram3 .sram3.*);
    . = ALIGN(4);
    } > SRAM3
  .sram4 (NOLOAD) : ALIGN(4) {
    *(.sram4 .sram4.*);
    . = ALIGN(4);
    } > SRAM4
} INSERT AFTER .bss;

I added the INFO logs to the error report and it seems the loadable sections are correctly set.

Here is the cortex-m-rt documentation on linker script: https://docs.rs/cortex-m-rt/0.6.12/cortex_m_rt/. At the minimum I need to set the RAM and FLASH memory regions.

I also tried these memory definitions from Electrosmith’s Arduino linker script:

MEMORY
{
    DTCMRAM	(xrw)	: ORIGIN = 0x20000000,	LENGTH = 128K
    ITCMRAM	(xrw)	: ORIGIN = 0x00000000,	LENGTH = 64K
    RAM_D1	(xrw)	: ORIGIN = 0x24000000,	LENGTH = 512K
    RAM_D2	(xrw)	: ORIGIN = 0x30000000,	LENGTH = 288K
    RAM_D3	(xrw)	: ORIGIN = 0x38000000,	LENGTH = 64K
    FLASH	(rx)	: ORIGIN = 0x8000000,	LENGTH = 128K
    SDRAM   (xrw)   : ORIGIN = 0xC0000000,  LENGTH = 64M
    QSPIFLASH (xr)  : ORIGIN = 0x90000000,  LENGTH = 8M
}

Whichever region I name RAM, the .data section updates but I always get the error at the same address: Failed to verify flash algorithm. Data mismatch at address 0x30000200.

[antoine]

I suspect the issue here may have more to do with probe-rs playing nicely with the programmer and/or MCU than the memory layout.

One other thing you could try is to leave off the exotic memories for now and try a minimal memory layout:

MEMORY
{
    FLASH  : ORIGIN = 0x08000000, LENGTH = 128K
    RAM    : ORIGIN = 0x20000000, LENGTH = 128K
}

Otherwise, I’ve posted a Rust starter for the Daisy using the more traditional openocd/semihosting/gdb setup here:

Rust starter for Daisy Seed

I got my Daisy Seed earlier this week (Tx Michael!) and put together a simple starter project for using the Daisy Seed with the Rust programming language: Currently it just implements a basic “blinky” which flashes the Seed’s user led. A good place to go digging for more example code is the examples directory in the stm32h7xx-hal crate. The instructions for use go something like this: Dependencies Install arm target for Daisy rustup target add thumbv7em-none-eabihf Install gdb # install …