BERGSONNE
Get started

Install & flash

Everything you need to build a firmware image for a Core tile and flash it over USB. If you only want to build in the browser, you can skip all of this and use Studio instead.

Prerequisites

The C SDK builds with the standard ARM embedded toolchain. You’ll need:

  • ARM GCC (arm-none-eabi-gcc) — the cross-compiler.
  • make — the build runner.
  • Python 3 — runs coregen, which generates the board headers every build depends on.
  • dfu-util — flashes firmware over USB.

On macOS with Homebrew:

brew install arm-none-eabi-gcc dfu-util make python

On Debian/Ubuntu, the equivalents are gcc-arm-none-eabi, dfu-util, make, and python3 via apt. Windows has a few extra steps — see below.

Whichever platform you’re on, this checks the whole toolchain at once and names anything that’s missing:

make doctor

Windows

The SDK builds on Windows, with one hard requirement: run it from Git Bash (or an MSYS2 shell), not cmd.exe or PowerShell. The Makefile uses POSIX shell tools throughout, and cmd.exe has none of them.

winget install Git.Git                        # provides Git Bash
winget install Python.Python.3.12             # tick "Add python.exe to PATH"
winget install Arm.GnuArmEmbeddedToolchain    # arm-none-eabi-gcc

Then open Git Bash (not the installer’s Git CMD) and run make doctor from the SDK folder. Three more Windows-specific things to know:

  • Paths with spaces don’t build. Make treats a space as a separator, so a project under C:\Users\First Last\… cannot be compiled at all. Keep the SDK and your projects somewhere like C:\dev\ — the build refuses up front and says so, rather than failing later with a confusing message.
  • python3 may be a stub. Windows ships an alias that opens the Microsoft Store instead of running Python. The Makefile probes python3, py -3, and python and picks one that actually runs; override with make PYTHON=… if needed.
  • dfu-util needs a driver. Install dfu-util, then use Zadig once to bind the WinUSB driver to the DFU device. Without it dfu-util reports no DFU-capable device even when the Core is plugged in and in DFU mode.

Build a firmware image

The SDK ships a starter project for every Core under templates/ — copy one, rename the folder, and make builds it as-is. See Quickstart for that path.

Building a project of your own, from any directory, means naming the Core variant with TILE. The build emits a .bin image:

make TILE=Core.ST.L4.1     # the Core's catalog id
# every Core has one — find yours in the catalog
The TILE value is the Core’s catalog id (the MCU and pin map differ across the Core family, so each variant builds differently). It’s printed on your tile and shown on the catalog page.

Flash over USB

USB-programmable Cores — currently Core.ST.L4 — support runtime USB DFU: no buttons, no jumpers, no probe. Connect the Core over USB and run:

make flash-dfu

The Makefile handles the whole sequence for you:

  • detects the USB serial port (/dev/tty.usbmodem* on macOS, /dev/ttyACM* on Linux),
  • sends a 1200-baud touch to trigger DFU mode (the same convention Arduino uses),
  • downloads the new firmware with dfu-util, and reboots.

Edit code, make flash-dfu, repeat. That’s the inner loop. Pass SERIAL_PORT=… if you have several boards attached and want to name the one to touch.

Flashing from Windows

Windows COM ports have no /dev entry, so the port can’t be auto-detected. Name it explicitly — find it under Device Manager → Ports (COM & LPT) — and install pyserial so the Makefile can perform the touch:

pip install pyserial
make flash-dfu SERIAL_PORT=COM5

Without SERIAL_PORT, make flash-dfu skips the touch and assumes the Core is already in DFU mode — hold BOOT0 while plugging in USB, then run it. Either way dfu-util needs the WinUSB driver bound with Zadig first.

First flash & manual DFU

For the very first flash on a board using the ROM bootloader, hold BOOT0 while plugging in USB, then flash normally — after that, make flash-dfu works on its own. To drive dfu-util by hand:

dfu-util -l    # verify the device appears: Found DFU: [0483:df11]
dfu-util -a 0 -s 0x08000000:leave -D build/my-firmware.bin

SWD debugging

For live debugging, flash via SWD with OpenOCD instead. SWD and USB DFU coexist — use SWD to step through code and make flash-dfu for quick iteration:

make flash     # flash via SWD (OpenOCD)
Going deeper
Bootloader modes (custom vs ROM), flash layout, the 1200-baud touch internals, and keeping a board recoverable are covered in Bootloading & flashing.