SL2610 Build and Flash with VS Code

This document provides concise, VS Code-only steps to build, generate images, and flash SL2610 applications. For common extension features (installation, tools, SDK import, logging, memory analysis), see Astra MCU SDK VS Code Extension User Guide.

Throughout this guide, <sdk-root> refers to the directory where you extracted or cloned the SDK.

Table of Contents

Prerequisites

Build and Deploy Flow

The Build and Deploy view allows running each step one at a time or sequentially.

If you check Build Configurations, Image Generation (SL2610), and Image Flashing (SL2610), all three operations run sequentially. Each step automatically fills in required information for the next step, such as the .elf file or sub-image path.

You may also run each step one at a time if desired.

The steps do not run until the Run button at the bottom of the view is pressed.

Environment Setup

  1. Import the SDK root and set workspace SRSDK_DIR to <sdk-root> via the Import SDK view.

  2. Import the project you want to build via the Import Project view.

  3. Open Build and Deploy from the Imported Projects view and set Device -> SL2610.

  4. If multiple projects are imported, select the correct project in the Build and Deploy project dropdown.

Build Configurations (SL2610)

Purpose: Generate .elf for SL2610 CM52 firmware.

Steps:

  1. Check the Build Configurations checkbox.

  2. If multiple projects are imported, select the correct project in the Build and Deploy project dropdown.

  3. Set Build Configuration to Release.

  4. Select the target Board and Compiler.

  5. Set Build Toolchain to GCC.13.2.1 when the field is available.

  6. Select the desired Application from the dropdown.

  7. Choose the appropriate build option:

Option

What it does

When to use it

SDK Build (default_package)

Generates the shared SDK foundation in <sdk-root>/install.

Use this first to prepare the common SDK package required by project builds.

Build (SDK+Project)

Builds the SDK components required by the app based on the app configuration, installs them into the app-local install folder, and then builds the example using that generated install package.

Use this when building an app for the first time and the required SDK components have not yet been generated for that app.

Build (Project)

Builds the active SL2610 project using project-local artifacts.

Use this during normal development when you want a fresh build for the selected project.

Build (Use Pre-built SDK)

Builds the active SL2610 project against the common install root in <sdk-root>/install.

Use this to reuse an existing SDK package and avoid rebuilding shared components.

Notes:

  • SL2610 builds only support Release mode from the extension UI.

  • If Build Configurations is disabled, verify that SRSDK_DIR is set correctly through the Import SDK view.

Result:

  • Build outputs are generated under the project’s out/sl2610_cm52_fw/release/ directory, for example out/sl2610_cm52_fw/release/sl2610_cm52_fw.elf.

SL2610 Build UI

Image Generation (SL2610)

Purpose: Convert MCU executables (.elf) into System Manager sub-images and the xSPI NOR flash images.

SL2610 Image Generator

Bootloader prerequisite: Before generating an SL2610 image, build the SL2610_RDK bootloader once from the imported SDK folder in VS Code:

  1. Open Build and Deploy for the imported SDK folder.

  2. Set Device -> SL2610.

  3. In Build Configurations, select:

    • Build Target -> bootloader

    • Build Configuration -> Release

    • Board -> SL2610_RDK

    • Compiler and Build Toolchain as required by your environment

    • A matching SL2610_RDK bootloader defconfig, for example sl2610_bootloader_rdk_defconfig

  4. Enable Build and click Run.

Bootloader result:

  • The bootloader build generates out/sl2610_bootloader/release/sl2610_bootloader.elf under the SDK root.

  • This bootloader artifact is required by the SL2610 image-packaging flow.

Steps:

  1. Open Build and Deploy for the imported SL2610 application project.

  2. Check Image Generation (SL2610).

  3. Use the Build and Deploy workflow to generate the image together with Build Configurations, or run Build Configurations once before image generation so the Release .elf is available.

  4. Confirm the pre-populated Release build path or use Browse to select a custom MCU executable. Note: This path is automatically populated after the build completes.

  5. Click Run. The extension uses the previously built SL2610_RDK bootloader together with the application .elf to package the SL2610 image outputs.

Result:

  • The System Manager sub-image is generated under out/image/eMMCimg/sysmgr.subimg.gz.

  • The xSPI NOR flash image is generated under out/image/XSPIimg/spi.bin.

  • Additional image-packaging outputs are generated under out/image/eMMCimg/, out/image/XSPIimg/, and out/image/USBimg/.

Note: Image Generation for SL2610 is available only on Linux platforms.

Image Flashing (SL2610)

Two supported methods:

  1. Yocto-based flashing: Astra Yocto Linux docs

  2. VS Code-based flashing (recommended for SL2610 development)

VS Code-Based Flashing

Before flashing, press and hold the USB_BOOT button, then press and release RESET.

If you are running WSL, please consult the Astra MCU SDK - WSL User Guide to ensure USB ports are properly handled.

  1. Check Image Flashing (SL2610).

The Image Flashing panel exposes three fields you must configure:

Field

Description

Storage Type

The destination flash on the board: eMMC or xSPI NOR.

Flash Target

What to write to that storage. Available options depend on the selected Storage Type (see below).

Image Path

Path to the image (or image folder, for Full Image) to flash. Auto-populated after image generation; use Browse to override.

Flash Target options by Storage Type:

Storage Type

Flash Target

Meaning

Expected Image Path

eMMC

M52 Image

System Manager sub-image only

out/image/eMMCimg/sysmgr.subimg.gz

eMMC

Full Image

Full eMMC image (GPT + partitions)

eMMC folder containing emmc_part_list and emmc_image_list

xSPI NOR

xSPI NOR Image

xSPI NOR flash image

out/image/XSPIimg/spi.bin

The supporting USB boot files (key.bin, spk.bin, m52bl.bin, sysmgr.subimg) are auto-derived from the same image output folder, so you only need to specify the Image Path above.

SL2610 Image Flashing

Per-target details

  • eMMC → M52 Image — Provide the sysmgr sub-image path. Auto-populated after image generation; use Browse to select a custom sysmgr sub-image (typically out/image/eMMCimg/sysmgr.subimg.gz).

  • eMMC → Full Image — Provide the eMMC folder path that contains emmc_part_list and emmc_image_list. The extension uses these files to determine partitions and image order for flashing.

  • xSPI NOR → xSPI NOR Image — Provide the NOR flash image, typically out/image/XSPIimg/spi.bin. Two optional erase modes are available:

    • Full Flash Erase — Performs a full chip erase, then continues into flashing the provided spi.bin (see Full Flash Erase (xSPI) below for the exact sequence).

    • Erase Only — Performs a chip erase without flashing any image afterward.

Full Flash Erase (xSPI)

When the Full Flash Erase checkbox is selected during an xSPI NOR flash, the operation runs in two phases with a mandatory USB reset in between.

Sequence:

  1. The xSPI flash chip is fully erased.

  2. The extension pauses and waits for a USB reset — a prompt appears in VS Code.

  3. Perform a USB reset on the board: press and hold USB_BOOT, then press and release RESET, then release USB_BOOT.

  4. Acknowledge the prompt in VS Code. Flashing of spi.bin resumes automatically and runs to completion.

The USB reset is required because the chip-erase phase leaves the device in a state where it must re-enumerate before the flashing phase can proceed. Skipping or delaying the reset will cause the second phase to time out.

Debugging (SL2610)

Debugging is not yet supported in the VS Code extension for SL2610.

Running Examples

For instructions on how to run a specific example, see that example’s README.