DEV Community

Hedy
Hedy

Posted on

How to program STM32 microcontroller?

#stm32 #stm32f103c8t6 #nucleof401re #stm32cubeide

Programming an STM32 is a pipeline of four layers:

1. Write firmware (source code)
You write C/C++ (sometimes Rust) that configures peripherals (GPIO, UART, timers, ADC, etc.) and implements your application logic.

2. Build (compile + link) into a binary
Your toolchain (GCC/Clang/IAR/Keil) turns code into:

  • .elf (debuggable output)
  • .bin / .hex (flashable image)

3. Program (flash) the binary into on-chip Flash
STM32 stores your firmware in internal Flash. You load it using one of the supported programming paths:

  • SWD (Serial Wire Debug) via ST-LINK/J-LINK (most common)
  • ROM bootloader (UART/I2C/SPI/USB DFU depending on chip) for “no debugger” flashing
  • Mass storage drag-and-drop (on boards with built-in ST-LINK)

4. Reset + boot sequence runs your app
On reset, the MCU fetches the reset vector from Flash and starts executing. BOOT pins (e.g., BOOT0) decide whether it boots from Flash or jumps to ROM bootloader.

Key concept: SWD vs Bootloader

  • SWD = best for development (debugging, breakpoints, “connect under reset”, fastest iteration)
  • Bootloader = best for production updates or rescue when SWD isn’t available

Practical paths (the 3 common ways)
A) SWD programming (recommended for engineering work)

Hardware: ST-LINK/V2 (or onboard ST-LINK on Nucleo/Discovery)

Signals you need (typical):

  • SWDIO
  • SWCLK
  • GND
  • 3V3 (VTref, recommended)
  • NRST (optional but very helpful)

Why it’s the best

  • You can flash + debug in one click
  • You can recover chips with “connect under reset”
  • Works even if your firmware breaks clocks/peripherals

B) ROM bootloader (no debugger required)

Most STM32 families include a factory ROM bootloader.

Typical boot entry logic

  • Set BOOT0 = 1
  • Reset
  • MCU runs the ROM bootloader and waits for UART/USB DFU/etc.

Why it’s used

  • Production line flashing
  • Field firmware update
  • “My SWD pins are not accessible” scenarios

C) Drag-and-drop (only on some dev boards)

Boards with ST-LINK often expose a “USB drive”. Copy .bin → it flashes.
Good for beginners, but SWD debugging is still the real workflow.

Example 1: STM32F103C8T6 (“Blue Pill”) via ST-LINK (SWD)
What you use

  • MCU/Board: STM32F103C8T6 (Blue Pill)
  • Programmer: ST-LINK/V2
  • IDE: STM32CubeIDE (or CubeProgrammer for pure flashing)

Wiring (most common)

  • ST-LINK SWDIO → Blue Pill PA13
  • ST-LINK SWCLK → Blue Pill PA14
  • ST-LINK GND → GND
  • ST-LINK 3V3 (VTref) → 3V3
  • (Optional) ST-LINK NRST → NRST

Workflow

  1. Create a project in STM32CubeIDE for STM32F103C8T6.
  2. Configure GPIO for an LED pin (many Blue Pills use PC13 LED).
  3. Build → get .elf and .bin.
  4. Click Debug (or Run). CubeIDE flashes via ST-LINK and starts debugging.
  5. Verify by toggling the LED in a loop.

Why this works well: F103 + SWD is simple, stable, and very common.

Example 2: STM32F401RE (Nucleo-F401RE) “one cable” programming + debug
What you use

Workflow

  1. Plug the Nucleo into PC via USB.
  2. Build your project in CubeIDE.
  3. Click Debug → it flashes and debugs automatically.

Best part: No external programmer wiring needed.

Example 3: STM32G030F6P6 (or similar) via UART bootloader (no ST-LINK)
What you use

  • MCU: STM32G030F6P6 (common low-cost STM32G0)
  • Tool: USB-to-UART adapter (3.3V logic)
  • Software: STM32CubeProgrammer

Typical steps (conceptual)

  1. Wire UART:
  • MCU USART_RX ↔ adapter TX
  • MCU USART_TX ↔ adapter RX
  • GND ↔ GND
  1. Pull BOOT0 high (how you do this depends on your PCB/board).
  2. Reset the MCU.
  3. In CubeProgrammer: choose UART, select COM port → Connect.
  4. Program .bin/.hex.
  5. Set BOOT0 low again and reset → app boots from Flash.

Why this matters: You can program a bare chip even without SWD access.

Common “it won’t program” reasons (fast diagnosis)

  • No common ground between programmer and target
  • BOOT0 left high → MCU stuck in bootloader
  • Wrong voltage / unstable power
  • SWD pins reused / noisy wiring → lower SWD speed, use short wires
  • Need NRST for “connect under reset” recovery

Quick rule-of-thumb for choosing the programming method

  • Developing firmware + debugging → SWD with ST-LINK
  • Factory flashing / field updates → ROM bootloader (UART/USB DFU)
  • Learning on Nucleo → onboard ST-LINK is easiest

Top comments (0)