STM32 to Blinky with Rust – Part 1 – Hardware – STM32F407G-DISC1
It’s been more than a decade since I last played with or programmed a microcontroller in anger, and wow, how the world’s moved on! The Arduino and its ATmega328P AVR is no longer king and now you can get an Arm Cortex-M0+ complete with a re-usable USB programmer for less than £10. For around £20 you can buy a development board with an Arm Cortex-M4F and some peripherals including an accelerometer, microphone, DAC, and USB OTG port.
Programming languages, compilers and toolchains have moved on too; C and Assembly aren’t the only games in town for low level microcontroller coding anymore. Rust has gained widespread support for many platforms and architectures and offers a memory safe way to run code on the bare-metal processor.
This series of blog posts will document my attempts to get a rust toolchain installed, compiling code for Arm Cortex M processors and deploying a small program on an STM32.
The first thing we need to do is install the basic rust toolset. There are probably some secure, supported, packages for Debian that you can apt install, but the last time I looked they were 2 years out of date. caveat emptor, running random shell scripts downloaded from websites is potentially dangerous; here be dragons.
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
The installer will update your shell’s configuration, setting up rust and its tools ready for your next login. Until that time, you can manually update your shell’s environment by ‘sourcing’ rust’s package manager, cargo‘s, script.
$ . ~/.cargo/env
With a proper rust environment set up, we now need to install the programmer/debugger tools. probe-rs integrates with the standard cargo tool to push compiled code to the chip and run it with a debugger. Installing it is similar to rust’s installation method, so the same warnings apply.
$ curl --proto '=https' --tlsv1.2 -LsSf https://github.com/probe-rs/probe-rs/releases/latest/download/probe-rs-tools-installer.sh | sh
Only the root user will have access to the USB programmer by default. To let regular users connect to the ST-LINK programmer we need add some udev rules.
First we need to find the USB ID for the ST-LINK, so we know which device to apply the rule to. There’s a good chance that the ID is 0483:374b, since that seems to be the same across most ST-LINKs I’ve seen, but it’s always safer to check first.
$ lsusb | grep ST-LINK
Bus 004 Device 002: ID 0483:374b STMicroelectronics ST-LINK/V2.1
To let local, logged-in, users connect to the ST-LINK programmer we need add a uaccess tag to it with a udev rule. Remote, SSH, users will need to be added to the plugdev group and then we can use the udev rule to apply that group and the 660 mode to the device.
$ sudo usermod -a -G plugdev $USER
$ exec sg plugdev newgrp
$ sudo vim /etc/udev/rules.d/70-usb-stlink.rules
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", MODE="660", GROUP="plugdev", TAG+="uaccess"
That rule and it’s clauses will be picked up on the next reboot, but we can force udev to read and apply it to any devices already connected with udevadm.
$ sudo udevadm control --reload
$ sudo udevadm trigger
Running probe-rs‘ list command will tell us which ST-LINKs have been detected, and its info command will then interrogate the chip its connected to about its configuration. If both succeed, we’ve probably got all of the permissions lined up to allow our user to program the chip.
$ probe-rs list
The following debug probes were found:
[0]: STLink V2-1 -- 0483:374b:066CFF575377524867052744 (ST-LINK)
$ probe-rs info
Probing target via JTAG
ARM Chip with debug port Default:
[…]
│ ├── PARTNO: Cortex-M4
[…]
Probing target via SWD
ARM Chip with debug port Default:
[…]
│ ├── PARTNO: Cortex-M4
[…]
That’s it for part 1. We’ve got the toolchain installed, connected the debugger and confirmed we can see the ARM chip ready for programming. Next we need to spin up a small project and send it to the programmer.
2024-06-20