Skip to main content

Building,Flashing and Debugging Embedded Rust Program

Building,Flashing and Debugging Embedded Rust Program

Building,Flashing and Debugging Embedded Rust Program

Building Program

  • Cargo provides 4 different targets that cover the different processor families within that architecture.
    • thumbv6m-none-eabi, for the Cortex-M0 and Cortex-M1 processors

    • thumbv7m-none-eabi, for the Cortex-M3 processor

    • thumbv7em-none-eabi, for the Cortex-M4 and Cortex-M7 processors

    • thumbv7em-none-eabihf, for the Cortex-M4F and Cortex-M7F processors

  • The one we are interested in is last one (i.e. thumbv7em-none-eabihf) because F3 has Cortex-M4F processor in it.  
  • Before cross compiling we have to download pre-compiled version of the standard library. For that we have to run:

$ rustup target add thumbv7em-none-eabihf

  • We have to download it once after that it will be updated automatically whenever we update rust tool chain. 
  • All set, we can now compile our program for whatever target we are compiling, using following command:

$ cargo build --target thumbv7em-none-eabihf

Flashing Program

Flashing => Moving program to MCU’s memory

Every time MCU will power on it will run the program flashed last time.


  1. Launch OpenOCD 
  2. Open GDB Server console 
  3. Connect GDB Server to OpenOCD 
  4. Load the program

 Launcing OpenOCD

We saw already what is OpenOCD, now let’s see how it works and how to initiate it. First we see how to initiate:
  1. Open up a new terminal

  2. Change directory to /temp (i.e. $ cd /tmp)

  3. Next run this command

$ openocd -f interface/stlink-v2-1.cfg -f target/stm32f3x.cfg


Now look at the above command carefully and the image below.


 Launching OpenOCD

We may observed that first we are interacting with st-link to target stm32f303.

The ST-LINK unveils a communication channel for us to target.

Initiating GDB Server

These commands only specific to gdb console. They haven't any meaning to our normal terminal/command prompt.

1.    $ <gdb> -q target/thumbv7em-none-eabihf/debug/<project-name>

<gdb> => this is System dependent debugging program to read arm binaries. It has 3 ariants gdb, gdb-multiarch* and arm-none-eabi-gdb

*In our case gdb-multiarch will work.

target/thumbv7em-none-eabihf/debug/<project-name> => Path to the binaries of projects we want to flash in MCU. 

Connecting OpenOCD

Previous command only opens gdb shell. To connect to Openocd      GDB Server run the following command. 

2.    (gdb) target remote :3333

This 3333 highlights the port number on which GDB server listens requests. And this command connects us to this port.

Connecting OpenOCD Above is the result of this command.

Loading Program

Now final step to flash our code to MCU’s persistent memory, once we connected successfully,

3.    (gdb) load

Debugging Program

Our program stopped at entry point after load command . There are few useful commands used for debugging purpose.

  • break

  • continue

break => this command is used to break program at certain point. For instance: We will run: (gdb) break main ,if we want to stop program at the start of main function.continue => this command would take us from one breakpoint to another breakpoint.

We may switch to GDB Text User Interface (TUI), for that run: (gdb) layout src ,for viewing line by line execution of program.  

We may run: (gdb) tui disable, for disabling TUI mode. While debugging run for resetting the program to initial state : (gdb) monitor reset halt. For terminating GDB session     (gdb) quit

Further commands:

  • step : for moving to next line

  • print : for printing values of variables

  • Info locals : this is for printing all values of variables at once

  • Clear shell : for clearing TUI screen



Popular posts from this blog

What is Internet of Things (IoT)?

 What is Internet of Things (IoT)?    The internet of Things, or IoT, refers to the billions of physical devices  round the  world that are now connected to  the web  , collecting, sharing and analyses  of knowledge  . It presents and provides the explanation of the network of physical things which is embedded with software , sensors,  and other technologies for the benefit of connecting and exchanging data with other devices and systems on the internet   . Due to the cheap processors and wireless networks, it's possible to  means  anything, from a pill to an aero plane to a self-driving car into  an area  of the IoT. Overview IoT will control the Fourth  technological revolution  . The Fourth  technological revolution  is changing the very software-defined automation allows manufacturers to link all stages of  the worth  chain, rapidly adapt to changing markets , and make highly personalized products on a mass scale. The opportunities provided by this revolution are authenticated

What is Rust Borrowing?

What is Rust Borrowing? Borrowing We call having references as function parameters borrowing. As in real world , if an individual owns something, we 'll borrow it from them . Whenever we’re done, we 've got to offer it back. Referencing  The reference is that the act of consulting somebody or something so as to urge information We would  declare reference in terms of Rust programing as if we are taking a replica of it without damaging or taking its ownership. ‘&’ symbol is employed to pass the reference Have a look that  how ‘&’ symbol is employed in code. fn main() { let s1 = String::from("hello"); let len = calculate_length(&s1); println!("The length of {} is {}.", s1, len); } fn calculate_length(s: &String) -> usize { s.len()} Mutable References The actual concept of mutable reference is same as we use mutable variable When  we  need to  modify  mutable reference is employed once   the worth we make regard to.

Kubernetes Readiness Probes

 Kubernetes Readiness Probes Description We understand that liveness probes and the way they assist keep our apps healthy by ensuring unhealthy containers are restarted automatically. Same like liveness probes, Kubernetes permit us to also define a readiness looked for our pod. The readiness probe is deployed periodically and examines whether the precise pod should receive client requests or not. Whenever a container’s readiness probe returns back success, it’s signaling that the container is ready to simply accept requests. This notion of being prepared is clearly something that’s specific to every container. Almost as liveness probe Kubernetes sends requests to container and supported the result either successful or unsuccessful response it decides container is prepared to require traffic or still preparing for that. The liveness probes not like, if a container fails the readiness check, it won’t be killed or restarted.   This is a very good practice to