Depending on what sort of wok you're doing, you may need to flash a dev board (or the real ZeroPilot) and debug your code in hardware to do things like observe signals with oscilloscopes or testing drivers or whatever.

There’s a few ways of doing this. The way I recommend is to use ST’s ide, but this guide will also explain the legacy way of doing it from the command line and setting up your own tools in a separate IDE.

Also, since you’re here and looking to deal with hardware, odds are your’e probably going to need ST's CubeMX tool to generate particular HAL drivers. If there’s no guide for doing that at the time you’re reading this, ask someone who knows what they’re doing to write one. But anyway, back to flashing/debugging.

Recommended way

For this, you're going to have to download ST's ID. There’s versions available for Linux, Mac and Windows, so you should be good. Now, here are the instructions:

In the IDE, create a new project. You can do this by clicking File->new->STM32 project.
This will open up the target selector.

In the part number field, enter the part number of the relevant microcontroller (STM32F765ZG for the autopilot chip and STM32F030RC for the safety chip). Choose that part and click next.
Now, give the project a name, select C++, empty, and click finish.
Now, click on the green bug in the task bar
This will pull up the debug configuration menu. You have to point the debugger to the elf file we built with our build system rather than the garbage that STM defaults to. So browse for the project. Our elf files are located in ZeroPilot-SW\Autopilot\build and are produced after a successful build.
Sweet, now just make sure your debugger is plugged in, connected to the board, and everything is powered on. Hit apply then OK to begin the debug session.
It is possible that upon launching the debug executable, ST has a hard time finding the source files. If that’s the case, just open the corresponding source files in the IDE (File->Open File)
Awesome, your’e good to go. If your’e new to debugging in an eclipse based IDE, I’d recommend looking for some tutorials on YouTube to get familiar with doing that.

The VSCode Way

For those who are not interested in downloading and installing cubeide, you should be able to make vscode handle intellisense, build, flash, and debug processes with some basic configuration.

This process makes use of the stlink suite. They are a set of command line tools that can be used to work with the st-link device. st-flash will flash a binary image onto the board, and st-util will start a gdb (GNU Debugger) server on the board. In order to successfully use both of these tools you will need to follow the directions on the appropriate project websites to install stlink and arm-none-eabi-gdb on your device.

You can check that the stlink package is installed by connecting a dev board with an stlink and running st-info --probe. From here you could simply flash the binary files you have already built per instructions from Firmware Development Environment Setup. If you want to try it, the command is st-flash write build/Safety.bin 0x08000000.

If you know how to use gdb, or are interested in learning gdb on the command line, go ahead and run st-util. You should receive a message along the lines of “Listening at *:4242...”. If you open a new terminal, and run arm-none-eabi-gdb ./build/Safety.elf, then type target extend localhost:4242 (or whatever port st-util has opened) you will be in a gdb session for the software you just flashed to the board.

Most sane people dont use debuggers on the command line, so lets put setup vscode to make use of these two tools we have set up. I personally have my workspace set up as a multi-root workspace for safety and autopilot.

Zeropilot.code-workspace:

{
	"folders": [
		{
			"path": "Safety"
		},
		{
			"path": "Autopilot"
		}
	],
}

Within each of Safety and Autopilot I have configured some tasks to flash and build the project.

Safety/tasks.json

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build Safety",
            "type": "shell",
            "command": "bash ./Tools/build.bash",
            "options": {
                "cwd": "${workspaceRoot}",
            },
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },
        {
            "label": "Flash Safety",
            "type": "shell",
            "command": "st-flash write build/Safety.bin 0x08000000",
            "options": {
                "cwd": "${workspaceRoot}",
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "dependsOn": [
                "Build Safety",
            ]
        },
    ]
}

To unlock the full power of VSCode from here, you will need to install some extensions:

C/C++ - from microsoft, provides intellisense (which I find to be very helpful) GitHub - microsoft/vscode-cpptools: Official repository for the Microsoft C/C++ extension for VS Code.
Cortex-Debug - Uses the stlink utilities to open a debugger session with the dev boardGitHub - Marus/cortex-debug: Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers

Below are my config files for the safety chip. They are similar for autopilot, but not identical. Make sure that you have the correct device configured.

Safety/c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Safety",
            "compilerPath": "/usr/bin/arm-none-eabi-g++",
            "cStandard": "c17",
            "cppStandard": "c++14",
            "intelliSenseMode": "linux-gcc-arm",
            "compileCommands": "${workspaceFolder}/build/compile_commands.json"
        }
    ],
    "version": 4
}

Safety/launch.json

With any luck, you should now have configured vscode to build, flash, and debug your code for the dev board. By default, Ctrl+Shift+B will run the default build task and F5 will open a debugger session.

Legacy way

This stuff is from before my time. If you’d like to try, have your hand at it.

Flashing is the process by which your computer communicates to an external programmer over USB, and flashes the target MCU with the binary you generated using the toolchain. The external programmers are called STLink progammers, and are designated by several version numbers. The ones we have in the bay are either STLinkV2 or STLink V2.1 programmers, and look like this:

These programmers connect to the Zeropilot board via a 5 pin cable that's usually custom made. They communicate over the SWD protocol, which also allows for in-step debugging! To actually flash the chip, you've got two options.

Using the official flashing software (Windows ONLY): To setup ST-link, visit ST-Link Drivers. Download the ST-link driver and ST-link utility. Once you download these, you should be able to connect to the board. You can verify this by opening the ST-Link utility and clicking "Connect" with the board powered and plugged into the programming port.
Using Open-OCD - this is an open source project that allows for debugging and flashing of MANY MCU and programmer combos. You can also integrate it with CLion to get debugging through the IDE

You don't need both! Either Open-OCD or ST-Link will do

Installation (Windows)

Install GNU Windows build tools
- so you have make on your system
Install the rest of the tools above, following the web page instructions

When installing CMake, make sure you tick the checkbox that asks if you wanna add it to you PATH

Installation (macOS)

Open up a terminal window
Install homebrew
Run. brew install git arm-gcc-bin cmake open-ocd
If you're installing Clion, installing CMake is optional in the above command ^^. Also make sure to install version 2018.3, and not the latest version!

Building

Clone the repo with: `git clone GitHub - UWARG/efs-zeropilot: Software for WARG custom autopilot `
If you have CMake locally installed and in your path, cd into ZeroPilot-SW/AutoPilot (or into ZeroPilot-SW/Safety if your'e developing for the safety chip) and run the build script with: ./Tools/build.bash. This will generate a .elf and .bin file inside the build/ folder that you can use for flashing.

Building with CLion

Once CLion is downloaded, open up either the Autopilot or Safety project. Make sure your version is 2018.3 and not the latest once, as a critical plugin isn't supported by the latest version
You should be prompted to install the OpenOCD + STM32CubeMX plugin. If not, go to Settings->Editor→Plugins and install it:

Afterwards, you should have listed a series of configurations for building the project on the top right:

Now you should configure CMake properly for the project. Go into Preferences→Build & Execution → CMake. Modify the Debug profile, and make sure the contents

of the CMake Options field are the following:

For the Safety project:

-DCMAKE_BUILD_TYPE="Debug" -DCMAKE_TOOLCHAIN_FILE="STM32F030xx.cmake"

For the Autopilot Project:

-DCMAKE_BUILD_TYPE="Debug" -DCMAKE_TOOLCHAIN_FILE="STM32F765xG.cmake"

Optionally modify the Release profile with the same settings, but the set the debug build type flag to be "Release" instead of "Debug"

Most of the time you'll wanna select the STLINKV2 configuration, since we have very few programmers that are STLINKV2.1. Click the play button to flash the chip, or the bug button to debug it!

Embedded Flight Software

Flashing/debugging