Last updated: July 2026. Specific electrical deltas below are quoted from the named datasheet revisions; verify against the exact part, package, and revision you design in, and against the alternate's own errata, not the STM32's.
The short version
When STM32 supply tightened, a group of Chinese MCU vendors with STM32F103-footprint lines went from curiosity to genuine second-source option: GigaDevice GD32, Geehy APM32, Artery AT32, WCH CH32, MindMotion MM32, Hangshun HK32. They're real parts, and for specific device-and-package pairs the nominal pin assignment matches the STM32F103 device they shadow, so a qualified swap can save a BOM in a shortage or shave cost. This guide is vendor-neutral: they are legitimate options.
Two precisions before anything else. First, those are vendor family names, not compatibility claims: each vendor offers particular lines aimed at particular STM32F103 devices, and nothing follows from that about the rest of the vendor's portfolio. A comparison holds for an exact part-and-package pair (say, an STM32F103C8T6 against its GD32F103C8T6 counterpart), never for a family name; density, package, ordering suffix, temperature grade, and silicon revision all participate. Second, "pin-compatible" here means matching nominal pin assignment. It earns the name without quotes only after a pin-by-pin electrical comparison of the exact parts: 5 V tolerance, analog capability, oscillator pins, reset behavior, boot straps, default states, drive strength.
And that's precisely where swaps go wrong, because pins matching says nothing about behavior matching. Read the documents side by side and you find specific, dated differences: a much higher reset threshold and minimum supply voltage, a different flash-latency mechanism, different USB clock dividers, and, tellingly, far thinner published errata. Any of these can turn a "compatible" swap into a board that won't start, won't program, or fails intermittently. None of them permanently damages anything; what they break is the swap, the schedule, and sometimes the field-return budget. Here's what actually differs, from the documents, and how to qualify one properly.
The candidates
All six vendors offer lines that target the STM32F103-class footprint and, with one important exception, the Arm Cortex-M ecosystem:
GigaDevice GD32: the most commonly compared alternative, Arm Cortex-M3, and the pair this guide opened primary sources for. Our worked comparison below is GD32F103 vs STM32F103.
Geehy APM32, Artery AT32, MindMotion MM32, Hangshun HK32: Arm Cortex-M alternatives with their own pin-compatible lines; Hangshun's and MindMotion's own materials state "pin-to-pin" compatibility, which is the kind of vendor claim you verify against the exact part and ordering code rather than trust.
WCH CH32, with a catch: the popular CH32V line is RISC-V, not Arm. Your existing Arm binaries cannot run on it, and source code has to be ported and rebuilt for RISC-V: new startup code, device headers, interrupt handling, linker scripts, and debug configuration, even though the compiler framework may still be GCC or LLVM. CH32 is a fine chip; just don't file it under "recompile and go."
The rest of this guide uses GD32F103 vs STM32F103 as the worked example, because it's the canonical pair and the one whose primary documents this guide actually opened. The method generalizes; the specific numbers are GD32's and must be re-checked for any other vendor.
The deltas that break a swap
These are from the vendors' own documents, not folklore. Each is the kind of difference a "pin-compatible" label hides.
1. Reset threshold and minimum supply: the "won't start" delta. GD32F103's power-on reset threshold is typically 2.40 V, and its power-down reset threshold depends on the device tier: typically 2.35 V on the smaller-flash parts (x4/6/8/B) but typically 1.85 V on the larger-flash parts (xC and above), per the datasheet's power-supply-supervisor tables. STM32F103's power-on/power-down thresholds sit around 1.88 V falling / 1.92 V rising (typical; max 2.0 V rising). Just as important: GD32F103's specified operating supply is 2.6–3.6 V, against the STM32F103's 2.0–3.6 V. So this delta bites in specific situations: a rail designed below 2.6 V is simply out of spec for the GD32 regardless of reset behavior; a supply with severe startup droop, a slow or non-monotonic ramp, or a brownout into the 2.0–2.5 V region can hold a GD32 in reset (or reset it) where an STM32 kept running. An ordinary, healthy 3.3 V rail with normal tolerance is not the problem case. Note these are the datasheets' typical figures: design margin comes from the limits and conditions in the current datasheet, and from testing your actual ramp.
2. Flash latency: a different mechanism, and a headline to distrust. STM32F103 uses clock-banded flash wait states that firmware must configure in FLASH_ACR: 0 wait states up to 24 MHz, 1 up to 48 MHz, 2 up to 72 MHz, per RM0008, with the documented prefetch settings. GD32F103's datasheet headline says the core runs "at 108 MHz frequency with Flash accesses zero wait states", but GigaDevice's own flash-programming manual (AN002) specifies address-banded access latency: 0 wait states for code in the first 256 KB of flash, 1 wait state for 256–512 KB, 2 wait states above 512 KB, and the GD32F10x user manual documents wait-state registers (FMC_WS, FMC_WSEN). In other words, the zero-wait headline is true for code living in the first 256 KB and not for everything above it, and the two GigaDevice documents don't tell one story; treat that as a documentation inconsistency to confirm with the vendor, not a spec you design against. The practical consequence is mechanism-independent: code whose timing was calibrated to the STM32's flash behavior (a cycle-counted delay loop, a bit-banged protocol tuned by trial) can run faster or slower on the GD32 depending on access pattern, code placement, and configuration. Timing-critical firmware is exactly where "it ran fine on STM32" stops being evidence.
3. USB clocking. Both parts derive the 48 MHz USB clock from the PLL through a prescaler, and the prescalers differ. STM32F103's RCC_CFGR has a single USBPRE bit: PLL divided by 1.5 or by 1, so valid USB means a PLL at 72 or 48 MHz. GD32F103's RCU_CFG0 has a two-bit USBD prescaler offering PLL divided by 1.5, 1, 2.5, or 2 (per GigaDevice's GD32F10x user manual and its own firmware library headers), which serves PLL clocks of 72, 48, 120, or 96 MHz. Two consequences. Firmware that pokes STM32 register values still produces a valid USB clock only in the configurations both parts share, such as 72 MHz with divide-by-1.5. And at the GD32's headline 108 MHz there is no divider that reaches 48 MHz, so a USB design picks a PLL frequency the USB prescaler can serve, not the maximum the core allows. Getting 48.000 MHz nominal is also only the entry ticket: USB clock tolerance, the D+ pull-up implementation, packet-memory details, and errata are their own checks.
4. The errata gap: the meta-delta. STMicroelectronics publishes a detailed, revision-specific errata sheet for the STM32F103 medium-density parts (ES096, Rev 15 as of March 2022: 40 documented silicon limitations with workaround status). On GigaDevice's own download portal, the Errata Sheet category filtered for GD32F103 returned "Errata Sheet (0 in all)" as of 2026-07-21, while the same portal carries errata sheets for several other GD32 families. That is very likely not because the silicon is flawless: it's a transparency difference, and absence from the portal is not evidence that no known limitations exist. Ask the vendor or distributor for device limitations in writing. Two cautions cut both ways here: don't assume your "mature" STM32 firmware already handles ES096 either, because workarounds live partly in libraries and partly in application code and are revision-specific; audit which ones you actually implement. And expect the bugs an errata sheet would have told you about to surface on your bench instead. Less published errata means more qualification work, not less.
5. A tooling trap. Even programming can bite. OpenOCD's mainline STM32F1 flash driver (src/flash/nor/stm32f1x.c, checked 2026-07-06) documents that several GigaDevice families share the STM32F1 medium-density device ID 0x410 and are told apart only by revision ID; the driver's comment records that a difference in option-byte bit offsets "caused problems e.g. during flash block programming because of unexpected active hardware watchdog," and the RISC-V GD32VF103 needed its own flash-write code path entirely. The comment names GD32F1x0, GD32F3x0, and GD32E23x explicitly; whether your exact part and probe combination is affected is precisely the kind of thing you validate, with the exact OpenOCD or vendor-tool version your production line uses, across erase, program, verify, option bytes, and the watchdog-active case. It's fixable, but it's the kind of thing that eats a day if you assume the existing toolchain "just works."
What's genuinely similar (the honest part): not everything is a trap. Both parts specify an ADC clock of up to 14 MHz and a maximum sampling rate of about 1 MSPS at minimum sample time, so the headline ADC throughput matches. That's one similar headline specification, not an equivalence: accuracy, calibration, input impedance requirements, trigger routing, and multi-ADC modes still need their own comparison. A vendor-neutral guide has to report the parity it found as carefully as the deltas.
Which alternative, and when
The six aren't interchangeable with each other, either: "a Chinese STM32 alternative" is a category, not a part. A rough guide:
GD32 (GigaDevice): substantial community experience and broad support in open-source and commercial tools, and the vendor documents this guide could actually verify against. A reasonable starting point for an STM32F103-class second source; verify the exact tool versions you depend on.
APM32 (Geehy), AT32 (Artery), MM32 (MindMotion): Arm Cortex-M alternatives with their own pin-compatible lines; each is its own qualification with its own reset, clock, and flash behavior. AT32 in particular advertises higher clock ceilings than the STM32 parts it shadows.
HK32 (Hangshun): markets explicit pin-to-pin compatibility; verify that claim against its datasheet exactly as you would any other.
CH32 (WCH): capable parts, but the popular CH32V line is RISC-V, a deliberate new-architecture choice, not a recompile-and-go STM32 swap.
The meta-point: each vendor is a separate qualification, and the deltas that matter (reset and supply thresholds, flash timing, USB clocking, errata depth) must be checked for the specific part you pick, never assumed from "GD32 works."
How to qualify a Chinese STM32 alternative
The method is the moat, and it's the same discipline as any datasheet-grade second source:
Read the alternate's own current datasheet, reference manual, and errata, not the STM32's. The whole failure mode is assuming the alternate behaves like the part it resembles. Get its actual reset thresholds, supply range, flash behavior, and clock specs from its own documents, at their current revision. Use the vendor's official full documentation, never a distributor summary; where the Chinese edition is newer or more complete than the English one, or only a Chinese document answers the question, read the Chinese source or get written vendor clarification.
Confirm your supply design against the alternate's minimum operating voltage and reset thresholds with margin, including ramp rate and brownout behavior. This catches the "won't start" delta.
Re-validate timing-dependent code (delay loops, bit-banged protocols, anything cycle-counted) on the real part, because flash and clock behavior differ by mechanism, not just by numbers.
Test the peripherals your firmware actually uses (especially USB, timers, ADC, and DMA) on hardware, against the alternate's own register documentation, not in theory.
Confirm your toolchain, debugger, and production programmer recognize and program the part cleanly, in the exact versions your line uses (mind the shared device IDs).
Treat "pin-compatible" as the start of qualification, not the end of it. For CH32V specifically, remember it's RISC-V: an architecture port, not a substitution.
These six steps screen for the failure modes in this guide and define the qualification plan; they are not, by themselves, a production qualification. A full second-source qualification still covers the exact ordering code and silicon revision, pin-level electrical comparison, boot configuration and option bytes, oscillator and clock characterization, low-power modes, flash endurance and programming in production, package and manufacturing details, quality and lifecycle documentation from the vendor, and corner testing across voltage, temperature, ramp, and silicon lots, with defined pass/fail criteria. Skip the corners and you can ship a failure that only appears at a voltage, temperature, ramp-rate, host, or lot extreme you never exercised.
FAQ
Is the GD32 a drop-in replacement for the STM32?
For specific exact pairs, the nominal pin assignment matches and substantial STM32-oriented code runs after a rebuild. Behaviorally, it's not a drop-in and shouldn't be treated as one: the documented differences (reset threshold and 2.6 V minimum supply, a different flash-latency mechanism with an internally inconsistent headline, different USB clock dividers, and far less published errata) mean you qualify the exact part on your hardware, not assume it. As a qualified second source it's legitimate and widely used; as an unverified swap it's a risk.
What's the single most important thing to check?
There isn't a universal one; it depends on your board and firmware. The reset-threshold and minimum-supply check comes first for a reason (it can prevent any execution at all, and it's cheap to do against your rail design), but for a solid 3.3 V system the deltas that dominate are more likely flash timing, USB clocking, boot configuration, or the programming toolchain. Rank the checks by your power architecture and the peripherals you actually use.
Are these Chinese MCUs reliable enough for a product?
Several of these vendors ship in high volume, but reliability isn't a class property and doesn't follow from volume or origin. It has to be established for the exact device, grade, package, and supply channel against your mission profile: request qualification and reliability documentation, check PCN/EOL practice and traceability, and budget your own testing. The transparency difference (thinner published errata) is one practical difference; supply commitments, tool support, and documentation depth are others. Qualify the specific part, then judge.
Is the WCH CH32 an STM32 alternative?
The Arm-core CH32 parts are in the same conversation, but the popular CH32V line is RISC-V: existing Arm binaries can't run, and source needs a real architecture and device port (startup, headers, interrupts, linker scripts, debug), even if you keep GCC or LLVM as the compiler. Treat CH32V as a new-architecture decision, not a second source.
Do I need to read the Chinese datasheets?
Use the vendor's official full datasheet and reference manual, never a distributor summary; that's the non-negotiable part. Several of these vendors publish official English documentation that carries the reset and timing specifications. The Chinese editions matter when they're newer or more complete, when an application note or errata answer exists only in Chinese, or when the two language editions disagree, and being able to read the Chinese original (or getting written vendor clarification) is the difference between a verified answer and a hopeful one.
Will my existing STM32 firmware run unmodified?
Split the question. An existing compiled binary: running it unmodified is not a supported compatibility claim anywhere; even where it appears to work on an exact Arm-compatible pair, production use needs a rebuild or a deliberate binary-validation program. Source code: for an exact GD32F103-class pair, substantial register-level code rebuilds and runs, but the deltas above (reset, flash timing, USB clocks) surface in corner cases, so you test on the actual part, exercising your actual peripherals and timing. Other vendors' families need their own porting assessment, and CH32V needs an architecture port.
How much cheaper are these than STM32?
It varies with the market and the shortage of the day, which is exactly why they matter. In an STM32 allocation, the alternative that's available and qualified beats the cheaper part you can't buy. Treat this as supply-security-plus-cost, not cost alone, and get the qualification done before you need it, so a swap is a purchase order rather than a redesign under a line-down clock.
Do these alternatives cover the newer STM32 families (F4, G0, H7)?
The alternative landscape is deepest around the STM32F103 class, which is what this guide covers; coverage of newer families varies by vendor and is generally thinner and less mature. If you're second-sourcing a newer STM32, confirm that a genuine pin-and-peripheral-compatible alternative exists for that specific part before you count on it: don't assume F103-class compatibility extends up the range.
Close
A Chinese STM32 alternative is one possible move to de-risk a BOM, and one of the easiest to get wrong, because "pin-compatible" reads like "done" and means "start here." The upside is real: supply security when STM32 goes on allocation, a cost advantage in many markets, and a swap that's a purchase order rather than a redesign under a line-down clock, provided the qualification is already done. The trade is real too: you're adding a second dependency, a Chinese vendor with its own supply risk, its own geopolitical exposure, and documentation whose decisive answers sometimes exist only in Chinese. And that qualification costs engineering time up front, on a part you may never ship. Whether the balance works depends on the product and on which risk you're actually trying to reduce. A Second-Source Map screens these parts the way they have to be screened (against their own current datasheets and errata, in the supplier's own language where that's where the answers live, on the deltas that actually break a swap) and names what still has to be qualified on your hardware. If that would help before you commit a design to one, that's what I do.
This article quotes specific documents: GigaDevice GD32F103xx Datasheet Rev. 2.15 (June 2023; general description and supply range re-verified 2026-07-21, electrical-table values as extracted from Rev. 2.12 on 2026-07-06 — re-verify tables against the current revision at publish), GD32F10x User Manual (FMC and RCU chapters) and AN002 flash-programming manual Rev 3.0, plus GigaDevice's GD32F10x firmware-library headers; STMicroelectronics STM32F103x8/xB datasheet (DocID13587, Rev 17 as opened; ST's current revision is newer, values unchanged per its revision history), RM0008 reference manual (Rev 20 as opened), and errata sheet ES096 Rev 15 (scope: STM32F101x8/B, F102x8/B, F103x8/B medium-density); and OpenOCD mainline source. Other parts, vendors, and revisions differ, and some widely-circulated compatibility notes could not be independently verified and are not relied on here. This is general engineering guidance: qualify any alternate against its own documents, errata, and your firmware before committing.
Get the next pattern by email
One dependency pattern from real hardware audits, occasionally. No schedule promised yet.
Working through this right now? Book a call → or write to me →