Most bad MCU decisions I've seen weren't made by bad engineers. They were made in a hurry, from a comparison table, in week one of a project — before anyone knew what the firmware would actually need to do. Six months later the team is stripping features out to fit in flash, or discovering the Wi-Fi stack eats 40% of the RAM budget, or explaining to a client why the certification bill doubled.
Choosing an MCU for a connected product is only about 20% silicon specs. The rest is update strategy, radio certification, security posture, supply chain, and how much of your calendar the vendor's SDK is going to consume. This is the checklist we work through with clients at UpNext before anyone orders a dev kit.
The datasheet answers a question you didn't ask
A datasheet tells you the best-case behaviour of one chip under ideal conditions. It tells you the maximum clock, the peripheral list, the sleep current with everything off and the moon in the right phase.
What it doesn't tell you:
- How much flash your application will have left after the vendor's Wi-Fi/BLE stack, a TLS library, a filesystem, and a bootloader with a rollback slot
- Whether the SDK examples compile cleanly, and whether the forums are full of people solving your bug or the vendor's
- What the real sleep current is with your pull-ups, your sensors, and a leaky level shifter on the board
- Whether the part will still be orderable in 2032
Those four items decide whether the product ships. So start there.
Do the flash and RAM maths for OTA first
If the product is connected, it needs field updates. Not "maybe later" — from day one. Security patches alone make that non-negotiable, and every serious IoT regulation now assumes it.
A safe OTA design usually means holding two application images: the running one and the one you just downloaded, so a failed update rolls back instead of bricking a unit in someone's basement. That effectively halves your usable flash. Add an immutable bootloader, a small key/config partition, and maybe a logging area.
So the rough model is:
- Total flash, minus bootloader, minus config/NVS, divided by two = your real application budget
- Then subtract the connectivity stack and crypto library from that half
On Wi-Fi-class parts, a TLS 1.2/1.3 stack plus certificate handling typically lands in the low hundreds of kilobytes of flash and tens of kilobytes of RAM once you account for TLS buffers. BLE-only designs are lighter but not free. This is why a part that looks generous at 512 KB flash can feel cramped fast, and why teams end up with awkward compromises like external SPI flash for the download slot — workable, but it's now a supply chain item, a driver, and a failure mode.
My rule of thumb: pick a part where your first working firmware uses under half the available application space. Firmware only grows. If you're at 80% at prototype stage, you've already lost.
A cheaper option that's often right
If your product has a phone app and doesn't need to talk to the cloud independently, BLE-only with the phone as gateway can cut cost, complexity, power draw, and certification effort substantially. Plenty of products ship Wi-Fi because it sounded more capable, then never use it. Be honest about the use case before adding a radio you'll have to support for a decade.
Choose the radio and the module before the MCU
This is the part people get backwards. The radio decision constrains everything: antenna design, RF layout, test equipment, certification, and your BOM.
The real fork in the road is pre-certified module vs. discrete chip-down design.
Pre-certified module
Higher unit cost — often a few dollars more per board. In exchange you inherit the module's radio certifications, you skip most RF layout risk, and you don't need a lab iteration cycle to pass emissions. For low-to-mid volumes, or a first-generation product, this is almost always the right call. I've rarely regretted recommending a module. I have regretted chip-down on a tight timeline.
Chip-down
Cheaper at volume, thinner, more design freedom. But you own the antenna matching, the RF test campaign, and full regulatory submissions for every market. It makes sense when volumes are high enough that the per-unit saving clearly beats the one-time engineering and certification spend, and when you have RF competence on the team or on retainer.
Also check which regions you're selling into early. A module certified for FCC and CE may still need extra work for other markets, and radio rules differ.
Security is now a line item, not a nice-to-have
Regulation has caught up. Between the UK's PSTI regime and the EU Cyber Resilience Act, connected products sold into those markets are expected to support secure updates, avoid universal default passwords, and have a defined vulnerability handling process. That has direct hardware consequences.
When shortlisting, look for:
- Secure boot with immutable root of trust — verified signature chain from ROM, not just "the bootloader checks a CRC"
- Hardware crypto acceleration for AES and ECC — software crypto on a small Cortex-M0+ will hurt both latency and battery life
- A true random number generator — you cannot fake entropy well on a deterministic MCU
- Key storage you can't read back — one-time-programmable regions, or an integrated secure element
- Debug port lockdown that you can actually enable in production without losing your ability to do RMA analysis
Decide your provisioning flow at this stage too. Per-device keys have to get into devices somehow, on a factory floor, possibly in another country. That workflow influences which chip family you want, because vendor tooling for secure provisioning varies enormously in quality.
Power: build a budget, then measure it
If the product is battery powered, sleep current dominates everything. Active current for 20 ms every ten minutes is noise; 15 µA of leakage running 24/7 is your battery life.
Build a spreadsheet with duty cycles: deep sleep current, wake time, radio transmit duration and current, sensor read time. Then treat the result as optimistic and go measure the real board. Common surprises we run into: an unused peripheral clock left running, a pull-up fighting a sensor's open-drain output, a regulator with poor quiescent current, and RTC configurations that quietly keep a high-speed oscillator alive.
Also check how the chip sleeps. Some parts retain all RAM in deep sleep at a modest current penalty; others retain only a few kilobytes, which means you're re-initialising the network stack on every wake and burning far more energy in reconnection than in sleep.
The boring things that actually kill projects
Lifecycle and availability
Ask the vendor or distributor for a longevity commitment in writing. Serious industrial MCU families come with published longevity programs measured in years, not vague reassurance. Check active distributor stock, check lead times, and check that there's a pin-compatible bigger sibling in the same family — because you will want more flash in revision two, and a drop-in upgrade is a very cheap insurance policy.
Toolchain and SDK quality
Your team will spend more hours inside the SDK than inside the datasheet. Before committing, spend two days doing a spike: flash the dev kit, get an RTOS task blinking, bring up the radio, do one OTA update over the air. If that takes two days, good. If it takes two weeks because the SDK examples don't build and the HAL is undocumented, that's your answer — and you found it for the cost of a dev kit instead of a project.
Debug and production test
Check that you get proper SWD/JTAG access, that trace is available if you'll need it, and that there's a sane way to run bring-up tests on the factory line. Designing test points and a production self-test hook in from the start saves painful weeks later.
Where edge AI changes the calculation
If any part of the roadmap involves on-device inference — anomaly detection on vibration data, keyword spotting, simple vision — say so now. Running even a small quantised model comfortably usually pushes you toward a Cortex-M33/M55-class part or one with a dedicated NPU, plus meaningfully more RAM for tensor arenas. Retrofitting that later often means a new board and a new MCU family. We do a fair amount of AI & ML development that ends up running on constrained hardware, and the earlier the model requirements enter the hardware conversation, the cheaper the whole project gets.
That said: don't add an NPU because it sounds future-proof. If you have no model, no training data and no clear use case, you're paying for silicon that will sit idle.
A practical shortlist process
What we typically do, in order:
- Write the firmware requirements first — what it senses, how often, what it sends, how it updates, how it's secured
- Choose the connectivity technology and decide module vs. chip-down
- Filter to two or three chip families with the right security features and a credible longevity commitment
- Add 2× headroom on flash and RAM against the early estimate
- Run a one-week spike on each dev kit: RTOS, radio, OTA, sleep current measurement
- Confirm pricing at your real volume, and confirm a pin-compatible upgrade path
- Commit
That's maybe two to three weeks of effort. It's the highest-leverage time you'll spend on the whole product.
Choosing an MCU for a connected product isn't about finding the most impressive chip. It's about finding the one that lets your team ship, patch, and support the thing for years without heroics. Boring, well-supported and slightly over-specified beats clever and cheap almost every time.
If you're at the architecture stage and want a second opinion — or you've inherited a design that's running out of flash — get in touch. Happy to look at your requirements and tell you honestly what we'd choose and why, including when the simpler, cheaper option is the right one. You can also browse our work to see the kind of products we've helped bring to market.