Is the STM32F4 still a good choice for new designs?

Yes, in specific circumstances. The STM32F4 has the deepest application note coverage, the largest community of examples, and the most mature third-party library support (FatFS, lwIP, FreeRTOS) of any STM32 series. For teams already familiar with the F4 toolchain — or porting an existing F4 design — it remains a practical choice. For greenfield designs with no legacy constraint, the G4 typically offers better power efficiency, a more modern peripheral set (including HRTIM and hardware op-amps), and comparable pricing. The F4 is not the right choice when low-power sleep modes matter or when the HRTIM-based motor/power control peripherals on the G4 are needed.

What is the difference between STM32H7 single-core and dual-core variants?

The STM32H743/H753 and H7A3/H7B3 are single Cortex-M7 core parts running at up to 480 MHz (H743) or 280 MHz (H7A3/H7B3). The STM32H745/H755 and H747/H757 are dual-core variants with a Cortex-M7 and a Cortex-M4 on the same die, allowing one core to handle hard real-time tasks while the other handles compute-intensive or OS workloads. The dual-core parts require ST's provided boot sequence and shared resource management. For most applications, the single-core H743 or H723 is simpler to bring up and sufficient; choose dual-core only when two independent execution contexts with hardware isolation are specifically required.

When should I use STM32WB instead of an nRF52 or ESP32?

Use the STM32WB when your product already depends on the STM32 HAL/CubeMX ecosystem and needs integrated BLE or IEEE 802.15.4 (Zigbee/Thread), avoiding a separate wireless SoC. The WB55 runs the BLE stack on its Cortex-M0+ co-processor, leaving the M4 application core entirely free — similar in concept to the nRF52840. Choose the nRF52840 instead if your project is BLE-centric and you want Nordic's mature NCS/Zephyr stack or long-range Coded PHY. Choose an ESP32 variant if Wi-Fi is required. The STM32WB has a smaller wireless community than nRF, but integrates well within a broader STM32 product architecture.

STM32

Which STM32 Family Should You Use?

Last updated 30 June 2026 · 9 min read

Direct Answer

STMicroelectronics organises STM32 into four broad tiers — entry-level (G0, C0), mainstream (F4, G4), high-performance (F7, H7), and ultra-low-power (L4, U5) — plus wireless-integrated families (WB, WL). For most new designs: choose the G0 for entry-level work (it replaces F0); the G4 for mixed-signal or motor control; the F4 for general-purpose work where community depth matters; the H7 for demanding compute, DSP, or camera/display; the U5 for battery-powered products; and the WB55 for BLE or Thread applications. Avoid starting new designs on F1, F2, or L1 — these are legacy series with no meaningful advantage over their modern equivalents. The right family is always the cheapest one that meets your performance, power, and peripheral requirements.

STMicroelectronics publishes more than 1,000 STM32 part numbers across 17 active product families. The family choice affects CPU architecture, maximum clock speed, power profile, peripheral set, and which HAL libraries and reference designs apply — getting it wrong early means a PCB respin.

The STM32 Family Tree

Every STM32 shares a common toolchain (STM32CubeIDE, STM32CubeMX, HAL/LL drivers) and debug interface (SWD/JTAG via ST-Link), but hardware capabilities vary substantially between families. ST organises them into four tiers, plus wireless-integrated families:

Tier	Families	Core	Primary use case
Entry-level	G0, C0, F0 (legacy)	Cortex-M0+	Cost-driven I/O and communications
Mainstream	F4, G4	Cortex-M4 (FPU + DSP)	General embedded products
High-performance	F7, H5, H7	Cortex-M7 / M33	Compute-intensive, DSP, multimedia
Ultra-low-power	L0, L4, L5, U0, U5	M0+ / M4 / M33	Battery-powered products
Wireless	WB, WL	M4 + M0+ (dual)	BLE, Thread, LoRa integrated

For designs starting now, focus on the families ST is actively investing in. Legacy series (F1, F2, L1) are still in production but receive no new HAL features and offer no advantage over their modern equivalents.

Family-by-Family Breakdown

STM32G0 — Entry-Level Mainstream

Core: Cortex-M0+, up to 64 MHz
Replaces: F0 series for new designs
Flash/RAM: 8 KB – 512 KB flash, 8 KB – 144 KB SRAM (device-dependent)
Key peripherals: UCPD (USB Power Delivery on G0B and G0C variants), up to five USART, I2C, SPI, 12-bit ADC, DAC, timers
Power: Standard active and sleep current — not optimised for ultra-low sleep
Best for: Cost-driven applications needing digital I/O, communication peripherals, and simple analogue. The G0B1 adds USB PD negotiation without an external PD controller, making it a strong choice for USB-C power sink designs. The G0 is the successor to the F0; prefer it for any application that would previously have used an F0.

STM32G4 — Mixed-Signal Mainstream

Core: Cortex-M4 with FPU + DSP, up to 170 MHz
Replaces: F3 (mixed-signal) and partially F4 for new designs
Flash/RAM: 32 KB – 512 KB flash, 22 KB – 128 KB SRAM (device-dependent)
Key peripherals: HRTIM (High-Resolution Timer), hardware op-amps, hardware comparators, 12-bit ADC at up to 5.33 MSPS per ADC block, DAC, FDCAN, USB
Power: Improved over F4; not ultra-low-power class
Best for: Motor control, switched-mode power supply (SMPS) control loops, digital audio, and any application needing high-speed analogue with M4 performance. The HRTIM generates complementary PWM pairs with configurable dead-time at sub-nanosecond resolution — a capability that is difficult to replicate with general-purpose timers on other families. For new designs in the F3/F4 performance class, the G4 is usually the better starting point.

STM32F4 — Legacy Mainstream (Still Viable)

Core: Cortex-M4 with FPU + DSP, up to 180 MHz (device-dependent)
Flash/RAM: 512 KB – 2 MB flash, 128 KB – 384 KB SRAM (device-dependent)
Key peripherals: ART Accelerator (zero-wait-state flash at full clock speed), Ethernet MAC, camera interface (DCMI), TFT LCD (LTDC on F429/F469), OTG USB HS/FS, 12-bit ADC
Power: Higher active and sleep current than G4 or L4
Best for: Designs porting from existing F4 boards; applications where Ethernet MAC or camera interface is required without stepping up to the H7; projects where the extensive F4 application note library, large community, and mature FatFS/lwIP/FreeRTOS examples are a genuine advantage.

STM32H7 — High-Performance

Core: Cortex-M7 with FPU + DSP, up to 480 MHz (H743); 280 MHz (H7A3/H7B3)
Flash/RAM: 128 KB – 2 MB flash; SRAM architecture is split across multiple banks (AXI SRAM, SRAM1/2/3, DTCM, ITCM) — total up to 1 MB on H743 (device-dependent)
Key peripherals: Dual Ethernet MACs (on some variants), JPEG codec, camera interface (DCMI), TFT LCD (LTDC), FMC (external SDRAM/NOR), OctoSPI/HyperBus, 16-bit ADC at up to 3.6 MSPS, AXI interconnect
Power: High active power — not suitable for battery-powered applications; the H7A3/H7B3 sub-family reduces peak power at the cost of lower maximum clock speed
Best for: Audio DSP, image processing, vision systems, applications needing external SDRAM or NOR flash, or any workload that genuinely saturates an F4 or G4 CPU. The H7 memory architecture requires careful attention: DTCM is not DMA-accessible, and the D-cache must be managed explicitly for DMA transfers; see the STM32H7 DMA TEIF and DTCM buffer discussion for a common bring-up failure.

STM32L4 — Low-Power Mainstream

Core: Cortex-M4 with FPU + DSP, up to 80 MHz (L4) or 120 MHz (L4+ sub-family)
Flash/RAM: 64 KB – 1 MB flash, 40 KB – 320 KB SRAM (device-dependent)
Key peripherals: ART Accelerator, 12-bit ADC, SAI (audio), DFSDM (digital microphone), OctoSPI (L4+), USB, LCD controller
Power: Typically below 100 nA in Stop 2 mode with RTC running — verified against STM32L4 Reference Manual electrical characteristics
Best for: Battery-powered embedded products requiring M4 performance with measured sleep current: wearables, remote sensors, portable instruments. The L4+ sub-family (L4R5/L4S9) adds external memory support and higher clock speed for more demanding applications.

STM32U5 — Ultra-Low-Power Modern Flagship

Core: Cortex-M33 with FPU + DSP + TrustZone, up to 160 MHz
Flash/RAM: 256 KB – 4 MB flash, 256 KB – 2.5 MB SRAM (device-dependent)
Key peripherals: LPUART, LPTIM, AES, PKA (public key accelerator), USBPD, OctoSPI, GPDMA (linked-list-capable DMA controller), TouchSense
Power: Typically below 300 nA in Stop 3 mode with RTC running — substantially lower than L4 in active mode at equivalent performance, per STM32U5 datasheet electrical characteristics
Best for: New battery-powered product designs where the application can also use TrustZone for secure boot, secure key storage, or isolated execution. The U5 is ST's recommended starting point for new ultra-low-power designs that would previously have used L4.

STM32WB — Wireless BLE and IEEE 802.15.4

Core: Cortex-M4 (application, up to 64 MHz) + Cortex-M0+ (wireless co-processor)
Flash/RAM: 256 KB – 1 MB flash, 256 KB SRAM (device-dependent)
Key peripherals: BLE 5.4, IEEE 802.15.4 (Zigbee/Thread), USB (WB55/WB35), 12-bit ADC, hardware AES-256
Power: Optimised for BLE connected sensor and beacon use cases
Best for: Products needing BLE or IEEE 802.15.4 within the STM32 ecosystem. The M0+ co-processor runs the BLE/802.15.4 stack independently, leaving the M4 application core free. The WB55 is the most capable and widely supported variant; ST provides the STM32WB Copro wireless firmware binary for the M0+ stack.

STM32WL — LoRa/LoRaWAN Integrated

Core: Cortex-M4 (up to 48 MHz) + Cortex-M0+ on dual-core WL55; single-core on WL33/WL5M
Key feature: Integrated sub-GHz radio (LoRa, FSK, BPSK, MSK) — compatible with the Semtech SX1262 radio interface
Best for: LoRaWAN end devices where a single-chip solution is preferred over a discrete MCU and external SX1262. The dual-core WL55 runs the radio stack on the M0+ co-processor, keeping the M4 free for application code.

Choosing by Application Type

Application	Recommended family	Key reason
Simple I/O, cost-sensitive	G0	Low cost, M0+, USB PD on G0B/G0C
Motor control / SMPS control loop	G4	HRTIM, hardware op-amps, fast ADC
General-purpose with Ethernet or camera	F4	Ethernet MAC, DCMI, deep community
DSP, audio, vision systems	H7	M7 core, 16-bit ADC, JPEG, external memory
Battery-powered (existing design ecosystem)	L4	Mature ultra-low-power M4, broad peripheral set
Battery-powered (new design, security)	U5	Lowest power class, TrustZone, 160 MHz M33
BLE or Thread product	WB	Integrated BLE 5.4 + 802.15.4, dedicated co-processor
LoRaWAN end device	WL	Integrated sub-GHz radio, no external radio SoC needed

Toolchain and Ecosystem Maturity

Every active STM32 family is supported in STM32CubeIDE and STM32CubeMX for graphical pin and clock configuration, HAL/LL code generation, and GDB debugging via ST-Link. For the configuration workflow, see How Do You Configure STM32 Peripherals with STM32CubeMX?.

The depth of community resources and third-party library maturity varies significantly:

Family	Community depth	Third-party library support
F4	Very deep (10+ years of community examples)	FatFS, lwIP, FreeRTOS, Mbed — all well-tested
H7	Good, but memory architecture produces frequent bring-up questions	Moderate; D-cache coherency adds integration work
G4	Growing quickly	Moderate; good for motor/power control; thinner than F4 for general libraries
U5	Newer; growing	Thinner than F4/H7; GPDMA API differs from classic DMA
WB	Moderate (wireless-specific community is smaller)	Good for BLE; thinner for non-wireless topics

Legacy Families — Avoid for New Designs

F0 — Superseded by G0. Still in production but offers no benefit over G0 for a new design.
F1 — Cortex-M3 at 72 MHz, no FPU, older peripheral architecture. A very large existing deployment base but no reason to choose it for a new design.
F3 — M4 with mixed-signal peripherals but at 72 MHz. The G4 provides the same mixed-signal capabilities at 170 MHz with a more modern HAL.
L1 — Ultra-low-power Cortex-M3 at 32 MHz. Superseded by L4 in both performance and power efficiency.

Common Mistakes

Choosing H7 for a peripheral-count problem — The H7 is tempting as a part that covers everything, but its memory architecture (multiple SRAM banks with different DMA access rules, explicit D-cache management for DMA buffers) adds significant bring-up time. Choose H7 only when the M7 core speed or the 16-bit ADC/JPEG/camera features are actually needed. See the STM32H7 DMA TEIF and DTCM buffer discussion for a typical H7 footgun when migrating from F4.

Starting a new design on F1 — The F1 (Cortex-M3, 72 MHz, no FPU) has no advantage over the G0, G4, or L4 for any new application. The community questions that surface for F1 are generally harder to answer because the HAL is less actively maintained.

Underestimating U5 GPDMA complexity — The U5's GPDMA controller supports linked-list-based transfers and has a different API structure compared to the DMA1/DMA2 on F4 or the MDMA/DMA on H7. Budget time for the initial GPDMA setup if migrating a DMA-heavy design from L4 or F4.

Selecting a family based on Nucleo board availability — ST makes Nucleo evaluation boards for almost every family. Nucleo availability is not a selection criterion; choose the family on its merits, then use the appropriate Nucleo or Discovery board for development.

If you're building a commercial product on the STM32 platform, Zeus Design provides STM32 firmware development from initial bring-up through production release.

Frequently Asked Questions

Is the STM32F4 still a good choice for new designs?: Yes, in specific circumstances. The STM32F4 has the deepest application note coverage, the largest community of examples, and the most mature third-party library support (FatFS, lwIP, FreeRTOS) of any STM32 series. For teams already familiar with the F4 toolchain — or porting an existing F4 design — it remains a practical choice. For greenfield designs with no legacy constraint, the G4 typically offers better power efficiency, a more modern peripheral set (including HRTIM and hardware op-amps), and comparable pricing. The F4 is not the right choice when low-power sleep modes matter or when the HRTIM-based motor/power control peripherals on the G4 are needed.
What is the difference between STM32H7 single-core and dual-core variants?: The STM32H743/H753 and H7A3/H7B3 are single Cortex-M7 core parts running at up to 480 MHz (H743) or 280 MHz (H7A3/H7B3). The STM32H745/H755 and H747/H757 are dual-core variants with a Cortex-M7 and a Cortex-M4 on the same die, allowing one core to handle hard real-time tasks while the other handles compute-intensive or OS workloads. The dual-core parts require ST's provided boot sequence and shared resource management. For most applications, the single-core H743 or H723 is simpler to bring up and sufficient; choose dual-core only when two independent execution contexts with hardware isolation are specifically required.
When should I use STM32WB instead of an nRF52 or ESP32?: Use the STM32WB when your product already depends on the STM32 HAL/CubeMX ecosystem and needs integrated BLE or IEEE 802.15.4 (Zigbee/Thread), avoiding a separate wireless SoC. The WB55 runs the BLE stack on its Cortex-M0+ co-processor, leaving the M4 application core entirely free — similar in concept to the nRF52840. Choose the nRF52840 instead if your project is BLE-centric and you want Nordic's mature NCS/Zephyr stack or long-range Coded PHY. Choose an ESP32 variant if Wi-Fi is required. The STM32WB has a smaller wireless community than nRF, but integrates well within a broader STM32 product architecture.

References

Related Forum Discussions

STM32F401 UART printing garbage after switching to 84 MHz PLL — same 115200 baud in CubeMX and PuTTY

Got a WeAct Black Pill (STM32F401CCU6) project that's been running happily on the default HSI clock at 16 MHz. Using USART1 on PA9/PA10 thro

STM32H743 HAL_UART_Receive_DMA fires error callback immediately — TEIF1 set, RxCplt never fires

Upgrading a project from STM32F4 to STM32H743. UART DMA receive worked on the F4 without any issues — standard CubeMX setup, call HAL_UART_R

STM32 GPIO interrupt configured but ISR never fires — what am I missing?

Trying to use a button on PA0 to trigger an interrupt on an STM32F411 Nucleo board. Using HAL, generated the init code with CubeMX. The GPIO

STM32 USB not detected by Windows after jumping to bootloader mode

Working on a custom STM32F411 board, trying to jump into the built-in USB DFU bootloader from application code instead of holding BOOT0 on p