Trevware

Trevware is a VS Code extension for developing STM32 firmware for Terps Racing EV (TREV). It brings building, debugging, ST-Link flashing, and CAN firmware updates into one workspace, with project configuration tailored to TREV boards and their bootloaders.

The extension uses STM32CubeMX-generated Makefile projects and supports C and C++. For STM32F405 and STM32L4 boards with CAN flashing enabled, it builds a standard firmware image plus two application bank images for the bootloader's update workflow.

Features

• Build and clean STM32 firmware projects from VS Code.
• Flash firmware over ST-Link/OpenOCD or CAN through a PCAN adapter.
• Generate STM32F405 and STM32L4 application bank linker scripts and firmware images.
• Read CAN bootloader metadata into flashing/metadata.log.
• Keep board identity and firmware version separate from compiler and source configuration.
• Generate build tasks, Cortex-Debug launch configuration, and IntelliSense settings.
• Discover source files and headers, configure compiler flags, and link static libraries.
• Check for the required build tools and offer automatic installation.

Getting started

Requirements

• VS Code with the Cortex-Debug extension.
• STM32CubeMX for generating the initial project.
• GNU Arm Embedded Toolchain (arm-none-eabi), Make, and OpenOCD. Trevware can check for these tools and offer to install them, or you can configure their paths in VS Code settings.
• An ST-Link probe for OpenOCD flashing and debugging.

CAN flashing also requires Python 3, Git for the flasher submodule, a PCAN adapter with the PEAK PCAN Basic driver, and a board running a compatible TREV CAN bootloader.

Set up a firmware project

1. In STM32CubeMX, select Makefile under Project Manager > Project > Toolchain/IDE.
2. Keep Copy all used libraries into the project folder enabled and generate the code.
3. Open the generated project folder in VS Code.
4. Click the Terps Racing icon in the activity bar and install or configure any missing build tools.
5. Select Build to generate the workspace configuration and compile the firmware.
6. Review trevware.config.yaml, especially the board ID, firmware version, and whether the board supports CAN flashing.

An existing flashing/stm32-build.config.yaml can also describe a custom project without a CubeMX Makefile. It must provide the required MCU, linker, source, and compiler configuration.

Commands

After the first build, use Ctrl+Shift+B on Windows/Linux or Cmd+Shift+B on macOS to run the build task. CAN actions are hidden when can_flashing_supported is false.

Project configuration

Board metadata

The root trevware.config.yaml contains the board metadata:

board_id: 0
reset_msg_can_id: 0
firmware_version: 0
can_flashing_supported: true

Set can_flashing_supported: false for projects using the original single-image layout.

Build output names come from the CubeMX Makefile's target, or the workspace folder name when no target is available.

Build and tool configuration

Edit flashing/stm32-build.config.yaml to configure source files, include directories, exclusions, compiler definitions and flags, static libraries, language, and the linker script. The generated YAML includes comments explaining its settings.

For C++ builds, set the build configuration's language to C++. You can provide main.cpp; if the project still uses main.c, Trevware creates a build copy at build/main.cpp when needed.

Trevware generates these supporting files:

The current VS Code settings and command IDs retain the stm32-for-vscode prefix inherited from the original extension. Tool settings include stm32-for-vscode.armToolchainPath, stm32-for-vscode.makePath, and stm32-for-vscode.openOCDPath.

CAN flashing

CAN Flash supports STM32F405 and STM32L4 projects with can_flashing_supported: true. It builds both application bank binaries and selects the flasher for the MCU family. STM32F405 uses F4-CAN-Flasher with the configured board ID and firmware version. STM32L4 launches the existing interactive terminal flow in STM32-CAN-Flasher.

When CAN Flash is invoked, Trevware adds or initializes the appropriate Git submodule at flashing/F4-CAN-Flasher or flashing/STM32-CAN-Flasher. The firmware project must be in a Git repository for automatic submodule setup. Activation, ordinary builds, ST-Link flashing, and metadata reads do not set up the submodule.

Once the flasher is available, install its Python dependencies using the same Python interpreter configured for Trevware:

python -m pip install -r flashing/F4-CAN-Flasher/requirements.txt

For L4, use Python 3.10+ and install flashing/STM32-CAN-Flasher/requirements.txt instead.

The L4 task copies the current build's bank binaries to build/debug/can-firmware/firmware_a.bin and firmware_b.bin (or build/release/can-firmware for release builds), then runs nogui.py with that directory as its working directory. Enter . at the Firmware directory prompt. Follow the prompts to select the adapter, channel, board, modules, verification, and jump behavior. These selections come from the flasher's prompts and boards.json; L4 does not use Trevware's board ID, reset CAN ID, firmware version, channel, or bitrate settings. The upstream terminal supports CANable and PCAN.

Use python3 if that is your interpreter's command. If the initial CAN Flash invocation stopped because dependencies were missing, install them and run it again.

Configure the F4 CAN connection in VS Code settings; the Python setting also applies to L4:

Read CAN Metadata is available for F4. It uses the existing flasher's read command and writes its output to flashing/metadata.log. If the flasher is missing, invoke CAN Flash to set it up first. For L4 bank status and manual controls, run python flashing/STM32-CAN-Flasher/main.py to open the upstream GUI.

Application bank layouts

With CAN flashing enabled, STM32F405 and STM32L4 projects generate the following application regions:

For STM32L4, the generated scripts preserve RAM regions and sections from the configured ldscript. That script must contain one FLASH memory region, and the source list must contain one system_stm32l4xx.c. A generated wrapper sets VTOR to the linked application address after Cube's SystemInit for the bank images.

Build and Clean Build produce the standard image using the original linker script and startup code, plus Bank A and Bank B. Debug outputs are:

build/debug/<target>.*
build/debug/bank-a/<target>-bank-a.*
build/debug/bank-b/<target>-bank-b.*

Release builds use the same structure under build/release/. Outputs include ELF, HEX, BIN, and disassembly files.

Flash STM32 programs both bank images over ST-Link/OpenOCD when the application bank layout is enabled, and the generated debug configuration uses the Bank A ELF. With can_flashing_supported: false, the extension builds, flashes, and debugs the standard image.

The bank images require an existing compatible bootloader. Trevware does not build or install that bootloader; the application bank scripts exclude its reserved flash region, including the area below 0x08008000 on STM32L4.

Credits and license

Trevware is based on STM32 for VSCode by Bureau Moeilijke Dingen, adapted for Terps Racing EV's firmware development and CAN update workflow. It is distributed under the MIT license, with the original copyright notices retained.