Program won't flash to board :(

[JOE1994]

Hello 🦀,

I got stuck while following the Discovery tutorial, and came here to ask for help :crying_cat_face:

I'm using my stm32f407 board instead of the stm32f3discovery board used in the tutorial. I've initially succeeded to flash a basic 'hello_world' program to my board. (a program that prints "hello world" via cortex_m_semihosting)

Now, comes the problem.. When I edit the program, rebuild it, and try to flash the new program to my board, it won't work. (The new program I'm trying to flash is also a program that just prints messages to the console via cortex_m_semihosting)

The load command in gdb loads size 0, meaning nothing is flashed to my board..

lonelyjoe@lonelyjoe-desktop:~/workspace/embedded/stm32f407g-disc1$ gdb-multiarch -q target/thumbv7em-none-eabihf/debug/stm32f407g-disc1
Reading symbols from target/thumbv7em-none-eabihf/debug/stm32f407g-disc1...done.
(gdb) target remote :3333
Remote debugging using :3333
0x00000000 in ?? ()
(gdb) load
Start address 0x0, load size 0
Transfer rate: 0 bits in <1 sec.
(gdb) 

I've looked at the embedded rust faq section on what to when a program won't flash, but the situation explained there is quite different from mine :cry:

I would really appreciate any kind of advice or guesses on how to fix this! :+1: Thank you for reading :+1:

p.s. below is my board loaded with a blinky C program (I built and flashed the C program to my board using the STM32CubeIDE)

[adamgreig]

Hi! The first thing I noticed is it's trying to load to address 0, which suggests your project might be missing a memory.x file. You need to put this next to Cargo.toml and fill it in with the right values for your chip. On the F407, it should look a bit like:

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

[JOE1994]

Hi, thank you for your comment! memory.x I've been using is as below. (I copy-pasted it from stm32f4-project-template)

MEMORY
{ 
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
  CCM (rwx) : ORIGIN = 0x10000000, LENGTH = 64K
  RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128k
}

When I run target remote :3333 from gdb-multiarch,

1. it always tries to load to address 0.
2. openocd gives me the message "undefined debug reason 7 - target needs reset"

I tried re-building my project with the memory.x that you suggested, but gdb-multiarch still tries to load the program to address 0.

I'm sure I should be doing something wrong here, because there are no issues flashing C programs to my stm32f407 board. I'm a total noob in embedded environments, so I'm unsure what's causing the issue :crying_cat_face:

[adamgreig]

Huh, odd! It still seems likely that something is wrong with the linker script somehow, here are a couple of things to try:

• Try using --release when building with Cargo and then make sure you're using target/thumbv7em-none-eabihf/release/stm32f407g-disc1 (note release instead of debug)

• Try dumping the ELF headers and pasting it here to check it's got the right sections: arm-none-eabi-objdump -h target/thumbv7em-none-eabihf/release/stm32f407g-disc1 (or install cargo-binutils and run cargo objdump ... instead).

Here's the headers from an example ELF for an STM32F405 I had lying around:

target/thumbv7em-none-eabihf/release/stm32f4-demo:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .vector_table 000001a8  08000000  08000000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00000198  080001a8  080001a8  000011a8  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       00000000  08000340  08000340  00001340  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .data         00000000  20000000  08000340  00002000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .bss          00000004  20000000  08000340  00002000  2**2
                  ALLOC
<additional sectors follow which aren't relevant>

[JOE1994]

Thank you for your feedback!! The dumped ELF headers are shown below. It's quite weird that my ELF headers don't have sections .vector_table, .text, .rodata, .data, and bss :scream_cat: :scream: This should be indicating that my linker script is incorrect, right? The original source code for this ELF is a very simple hello world app (I added the source code below also)

1. My ELF headers

   
   lonelyjoe@lonelyjoe-desktop:~/workspace/embedded/stm32f407g-disc1$ arm-none-eabi-objdump -h target/thumbv7em-none-eabihf/release/stm32f407g-disc1

target/thumbv7em-none-eabihf/release/stm32f407g-disc1: file format elf32-littlearm

Sections: Idx Name Size VMA LMA File off Algn 0 .ARM.attributes 0000003a 00000000 00000000 00000094 20 CONTENTS, READONLY 1 .debug_str 0002e177 00000000 00000000 000000ce 20 CONTENTS, READONLY, DEBUGGING 2 .debug_abbrev 00000678 00000000 00000000 0002e245 20 CONTENTS, READONLY, DEBUGGING 3 .debug_info 000262b2 00000000 00000000 0002e8bd 20 CONTENTS, READONLY, DEBUGGING 4 .debug_aranges 00002358 00000000 00000000 00054b70 23 CONTENTS, READONLY, DEBUGGING 5 .debug_ranges 000165a8 00000000 00000000 00056ec8 20 CONTENTS, READONLY, DEBUGGING 6 .debug_macinfo 00000002 00000000 00000000 0006d470 20 CONTENTS, READONLY, DEBUGGING 7 .debug_pubnames 000084f7 00000000 00000000 0006d472 20 CONTENTS, READONLY, DEBUGGING 8 .debug_pubtypes 00002761 00000000 00000000 00075969 20 CONTENTS, READONLY, DEBUGGING 9 .debug_frame 00006608 00000000 00000000 000780cc 22 CONTENTS, READONLY, DEBUGGING 10 .debug_line 000269e8 00000000 00000000 0007e6d4 20 CONTENTS, READONLY, DEBUGGING 11 .comment 00000092 00000000 00000000 000a50bc 20 CONTENTS, READONLY

2. original source code
```rust
#![no_std]
#![no_main]

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

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

#[entry]
fn main() -> ! {
    hprintln!("Launch Program").unwrap();

    loop {

    }
}

[adamgreig]

Could you check if your .cargo/config file in your crate has something like:

[target.thumbv7em-none-eabihf]
rustflags = [
  "-C", "link-arg=-Tlink.x",
]

[build]
target = "thumbv7em-none-eabihf"

Specifically the link-arg setting is required to tell the linker to use the link script.

[JOE1994]

I do have the items in my .cargo/config file as below: mine doesn't have the gate [target.thumbv7em-none-eabihf] before the rustflags item.

rustflags = [
  # 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)

[JOE1994]

I just added the gate [target.thumbv7em-none-eabihf] right before rustflags in my .cargo/config, and now the ELF headers are showing me the missing sections :cat:

lonelyjoe@lonelyjoe-desktop:~/workspace/embedded/stm32f407g-disc1$ arm-none-eabi-objdump -h target/thumbv7em-none-eabihf/release/stm32f407g-disc1

target/thumbv7em-none-eabihf/release/stm32f407g-disc1:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .vector_table 00000400  08000000  08000000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         000005b8  08000400  08000400  00001400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       00000094  080009b8  080009b8  000019b8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .data         00000000  20000000  08000a4c  00002000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .bss          00000008  20000000  08000a4c  00002000  2**2
                  ALLOC
  5 .uninit       00000000  20000008  08000a54  00002000  2**2
                  ALLOC
  6 .ARM.attributes 0000003a  00000000  00000000  00002000  2**0
                  CONTENTS, READONLY
  7 .debug_str    0002e177  00000000  00000000  0000203a  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_abbrev 00000678  00000000  00000000  000301b1  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_info   000262b2  00000000  00000000  00030829  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_aranges 00002358  00000000  00000000  00056ae0  2**3
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_ranges 000165a8  00000000  00000000  00058e38  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_macinfo 00000002  00000000  00000000  0006f3e0  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_pubnames 000084f7  00000000  00000000  0006f3e2  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_pubtypes 00002761  00000000  00000000  000778d9  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_frame  00006608  00000000  00000000  0007a03c  2**2
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_line   000269e8  00000000  00000000  00080644  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .comment      00000092  00000000  00000000  000a702c  2**0
                  CONTENTS, READONLY

[JOE1994]

@adamgreig Thank you so much for your help! I've now successfully flashed the program to my stm32f407 board! :smiley:

[adamgreig]

Ah great, glad to hear it!

[therealprof]

@JOE1994

Shameless plug: There's a crate specifically for the F407 Disco. It doesn't have a ton of stuff but maybe some material to get you started: https://github.com/stm32-rs/stm32f407g-disc

[JOE1994]

@JOE1994

Shameless plug: There's a crate specifically for the F407 Disco. It doesn't have a ton of stuff but maybe some material to get you started: https://github.com/stm32-rs/stm32f407g-disc

Thank you for the info! :superhero: