STM32CubeIDE for Visual Studio Code Documentation

Table Of Contents

- STM32CubeIDE for Visual Studio Code
- Introduction
  - Overview
  - System requirements
  - Release note
- Basic Concepts
  - User interface
  - Command-line tools
  - Visual Studio Code extension packs
  - Bundles
  - CMake
  - Toolchains
  - STMicroelectronics Arm Clang Toolchain for STM32
- Getting Started
  - Installation
  - First project creation
- Workspace and extension workflow
  - Workspace overview
  - Extension commands
  - Project files
  - Multi-project workspaces
- Tutorials
  - Migrating from STM32CubeIDE for Visual Studio Code extension 2.x to 3.x
  - Dual-core STM32 projects
  - Power management
  - RTOS-based STM32 projects
  - Firmware security and integrity
- Development
  - Projects
  - Editing
  - Build
  - Debug
  - API manual
  - Integration with external tools
  - Testing and validation
- Troubleshooting
  - Frequently asked questions
  - Known issues
  - Support

### On this page

- Use the correct build artifacts
- Development programming in Visual Studio Code
- Release programming with tasks
- Release traceability
- Update architecture choices
- Validation before rollout
- Typical failures and recovery

# Firmware deployment and update workflow

This chapter describes a deployment workflow specific to STM32CubeIDE for Visual Studio Code.

It covers three areas included in this documentation set:

- Build artifacts produced by the STM32 build flow

- Programming during development through debug configurations

- Repeatable release programming through project tasks

This chapter does not require a specific production programming utility. The programming command depends on the product process and hardware setup.

## Use the correct build artifacts

The build chapter defines the primary artifacts used during STM32 development:

- `.elf` for debug sessions and symbol-aware analysis

- `.hex` and `.bin` for programming and update packaging

- `.map` for memory review and release traceability

In STM32CubeIDE for Visual Studio Code, these files are produced by the active build configuration, typically `Debug` or `Release`.

For artifact definitions and output context, see Build.

## Development programming in Visual Studio Code

For daily development, use the Run and Debug workflow described in the debug chapter.

Recommended sequence:

1. Build successfully to generate the current `.elf`.

2. Open Run and Debug and create `launch.json` if needed.

3. Select the correct debug probe configuration, such as `stlinkgdbtarget` or `jlinkgdbtarget`.

4. Start the debug launch and verify that the image and symbol path are

> correct.

Practical guidance:

- Maintain one debug configuration per target board

- Use explicit names in `launch.json` for multi-target projects

- Enable `preBuild` to ensure each debug session flashes the latest build output

For debug configuration details, see Debug.

## Release programming with tasks

For release and manufacturing preparation, define programming steps as workspace tasks instead of manual terminal commands.

Why this approach is preferred in this environment:

- The command is version-controlled in `.vscode/tasks.json`

- Team members run the same command from the same workspace

- Terminal output can be archived with the release record

Minimum task set for release preparation:

1. Build the `Release` configuration.

2. Program the target with the approved production command.

3. Run a post-program verify step.

4. Save command output as release evidence.

For task configuration patterns, see Build and Projects.

## Release traceability

Each release candidate should include a small manifest that links the image to its source and tool context.

Recommended manifest fields:

- Product identifier

- Firmware version

- Source revision

- Artifact names for `.elf`, `.hex`, and `.bin`

- Checksum or hash values used by the process

If the team uses bundle pinning, also record the bundle baseline used to build the release. The command-line toolbox chapter describes bundle-oriented project setup and installation.

For CLI context, see API manual.

## Update architecture choices

STM32CubeIDE for Visual Studio Code supports different firmware update architectures. The IDE does not require a specific model.

Common models:

- A/B image slots with controlled switchover

- Single application slot with a recovery loader

Selection criteria:

- Available flash and non-volatile memory budget

- Recovery requirements after an interrupted update

- Bootloader capabilities in the product

Define update-state flags, integrity checks, and rollback rules in the product specification before implementation.

## Validation before rollout

Before release approval, verify at least the following on target hardware:

1. Programmed artifact matches the expected release artifact.

2. Reported firmware version matches the release manifest.

3. Device boots cleanly after a power cycle and reset.

4. Critical peripherals initialize and run as expected.

5. Watchdog and fault-recovery behavior are validated.

Recommended evidence to archive:

- Build log for the released artifacts

- Programming and verify logs

- Test verdict summary

## Typical failures and recovery

Use predefined recovery steps for the most common deployment failures.

- Image mismatch after programming

  - Stop deployment for that target

  - Re-run the program and verify sequence

  - Keep logs for root-cause analysis

- Boot failure after update

  - Recover using the product rollback path

  - Capture failure context from debug tools

  - Re-test with the last known-good image

- Functional regression on the updated image

  - Pause rollout

  - Reproduce with the exact release artifact set

  - Resume rollout only after corrective validation