When your microcontroller goes end-of-life

An end-of-life notice on the microcontroller you built around never arrives at a convenient time. It usually shows up as a one-line email from a distributor, a status flag that flips on a parametric search, or a lead time that quietly slides from eight weeks to fifty-two. By the time someone notices, the clock has already started.

What an EOL or NRND notice actually starts

“End-of-life” and “not recommended for new designs” are different signals, and it’s worth knowing which one you’re looking at. NRND means the manufacturer will keep building the part for existing customers but doesn’t want you designing it into anything new — it’s an early warning, not a deadline. An EOL notice is the deadline: it comes with a last-time-buy (LTB) window, usually a few months, after which the part simply stops being made. Distributor stock outlives that date for a while, sometimes years for a popular part, but stock is not the same as supply — the day a fab line shuts down, the number of units in the world stops growing.

The mistake we see most is treating either notice as a firmware or purchasing problem instead of a schedule problem. The moment a notice lands, there’s a number of units still needed to cover the gap until a redesign ships, and that number determines whether you’re buying time with an LTB order or immediately starting a respin. Both take work to get right, and both take longer than they look like they should from the outside.

The four ways to respond

Last-time buy. Order enough of the part, all at once, to cover production through the redesign — or, for a product near the end of its life anyway, through its remaining run. This is the cheapest option in the short term and the only one that requires zero engineering. The trade-off is capital tied up in inventory, storage and handling for parts that may sit for years, and the risk of getting the quantity wrong in either direction. It buys time; it doesn’t solve the underlying problem.

Drop-in alternate. Some manufacturers publish a pin-compatible, code-compatible successor to a discontinued part specifically to avoid this problem — think of the newer STM32 lines that stayed pin-compatible with an older footprint, or a Microchip PIC replaced by a part in the same family with the same pinout and peripheral set. When this exists, it’s the best outcome: no layout change, minimal firmware change, and a short qualification cycle. It’s rare enough that you shouldn’t assume it exists until you’ve checked.

Pin-compatible family member. One step down from a true drop-in: a part in the same family, same package, same pinout, but with a different peripheral set, more or less flash, or a different silicon revision. The board doesn’t need a respin, but the firmware needs a real review — register maps, interrupt vectors, and peripheral behavior can all differ even within one family.

Redesign. When nothing in the original vendor’s lineup fits — the family itself went EOL, the package changed, or the replacement doesn’t have the peripherals the product needs — the answer is a new microcontroller, sometimes from a different vendor entirely. This is the most work and the most risk, but it’s also the option that puts the product on a part with a longer runway instead of buying a few more years on a part that’s already been discontinued once.

Which of these applies isn’t always obvious from the datasheet alone — it usually takes a call to the vendor or a distributor FAE to find out what’s actually still being made versus what’s listed as “active” out of inertia.

How to qualify an alternate properly

Whichever option applies, qualifying the replacement is where projects lose the most time to surprises. A proper qualification covers:

Check	What it catches
Datasheet diff, line by line	Electrical characteristics, timing, pinout differences
Errata sheet	Silicon bugs that change how you have to use a peripheral
Package and footprint	Whether the board needs a respin at all
Peripheral map	Which timers, ADC channels, and communication blocks moved pins or disappeared
Supply chain, more than one distributor	Whether the “alternate” is itself already low-stock or NRND
Lifecycle status of the alternate	Whether you’re about to repeat this exercise in two years

That last line matters more than it looks like it should. We’ve seen alternates chosen under time pressure that were themselves flagged NRND within eighteen months, because nobody checked the lifecycle status of the part being qualified as the fix — the same trap we walk through for second-sourcing a single flash part.

What usually breaks when you port firmware to a different vendor

Moving firmware across microcontroller families — say, an STM32 project to a Nordic nRF52, or a Microchip PIC to a TI MSP430 — is where the real engineering work lives, and where a schedule tends to slip if it wasn’t budgeted for honestly.

The clock tree and PLL setup are almost never a copy-paste. Every vendor has its own way of deriving core, peripheral, and USB clocks from a crystal or internal oscillator, and getting it wrong doesn’t always fail loudly — sometimes a UART baud rate is off by half a percent and nothing looks wrong until it does. Peripheral naming and DMA are the next trap: a “timer” on one vendor’s part is not necessarily the same capability as a “timer” on another’s, and DMA channel assignment, triggering, and buffering models differ enough that code built around one vendor’s DMA controller usually needs to be rethought, not translated. Bootloader and flash layout need a fresh look too — different flash page sizes, different reserved regions, and a different in-system programming protocol all affect how updates get delivered in the field. HAL and SDK differences are the most visible but not the most dangerous: STM32’s HAL, Nordic’s SDK, Microchip’s MPLAB Harmony, and TI’s driverlib all model the same hardware in different ways, and a straight function-for-function port tends to carry over the previous vendor’s assumptions in ways that don’t show up until integration testing. Debug tooling changes too — a different programmer, a different IDE, sometimes a different instruction set entirely if the redesign moves off ARM Cortex-M — which is a real cost even when nobody puts it on the project plan.

The mechanical knock-ons

A part that isn’t pin-compatible drags mechanical design along with it. A different footprint means the layout moves, which can move keep-out zones, which can push into space the enclosure was designed around. Where possible, we hold the connector and the enclosure fixed and let the internal layout absorb the change — that keeps the product’s tooling, cabling, and field-service parts unaffected even when the board inside it is new. When the enclosure has to change too, that’s a second design cycle stacked on the first, and it’s worth knowing that going in rather than discovering it during fit-check.

How to test the respin

A respin, however small it looks on paper, gets tested like a new board. That means a bring-up checklist before anything else runs — power rails in tolerance, clock present and correct, programming and debug interface responding — followed by a side-by-side comparison against a known-good unit of the original design, checking that behavior matches on every interface the product exposes, not just the ones that were expected to change. From there it goes through the same production test the original board runs, because a fixture built for the old part’s pinout and timing usually needs updates of its own, and that update is easy to forget until the first unit fails a test that was never rewritten. Only after that does it get treated as a released design.

What to send us

If a part you’ve built around just went EOL or NRND, the fastest way to get a straight answer is to send: the notice itself, the current schematic and BOM, the quantities and timeline you’re working against, and any firmware source that exists. From that we can tell you within a day or two which of the four paths above actually applies to your board, and what it would take.