Moving off an NXP S08 before the last-time-buy date
A product that has shipped for ten years on an NXP MC9S08 gets an email. The fab that makes the chip is closing, nothing is moving to another site, and there is a last-time-buy date. The firmware works. The board works. Now someone has to decide how much to buy, and whether to start a port.
This note is about that decision. It covers what the notice says, what it leaves out, and how to turn it into a plan.
What the notice says
NXP published product discontinuation notification 202608007DN on 6 August 2026. It covers the closure of the Chandler, Arizona fab and probe facility. NXP says it has agreed to sell the site in phases, and that the legacy technologies and products that will not move to another NXP site are being discontinued.
For the parts in the table we read, the notice gives:
| Item | What the notice states |
|---|---|
| Last time buy | 6 August 2027 |
| Last time delivery | 6 August 2028 |
| Site transfer | None |
| Status | Full withdrawal, limited availability, sole source |
The table covers a wide range of NXP parts. The entries we saw include MC9S08 and other S08-family microcontrollers, MC908 and HC08 parts, MC56F digital signal controllers, MCF51 ColdFire parts, and a long list of MC33xxx and MC34xxx analog and power devices. The page we read was long and truncated, so we could not confirm every part number. Your first job is to search the full notice for your exact orderable part number, not the family name.
Three details in the notice matter for planning:
- Availability is limited. Last-time-buy orders are first come, first served until inventory or capacity runs out. NXP also states that acceptance of a last-time-buy order is not guaranteed.
- Most entries list no replacement. A few show one. Where NXP names a substitute, it says the substitute may need evaluation, testing or qualification and may not be a drop-in.
- The dates need confirming. The notice’s policy text and its table do not obviously agree on the length of the last-order period for sole-source parts. Treat 6 August 2027 as the working date and confirm it with NXP or your distributor in writing.
The notice does not say the chips disappear on that date. It says NXP will stop taking orders, then stop delivering. Distributor stock and broker stock are separate questions, and we would not plan around either.
Check the whole bill of materials, not just the microcontroller
An S08 is usually the part people notice. The same notice lists power-management and analog parts in the MC33xxx family, and a board with an S08 often has one of those beside it. Run every NXP line on your bill of materials against the notice. A design can survive losing the microcontroller and still be stuck on a regulator or a system-basis chip.
For each NXP line, write down:
- The exact orderable part number, including suffix and package.
- Whether it appears in the notice, and what the notice lists for it.
- Whether NXP names a replacement, and what the replacement’s datasheet says about pinout and electrical differences.
- Your annual usage, from real build history rather than a forecast.
That table is the input to everything below. If you do not have a clean bill of materials, building one is step zero. Our note on last-time buys covers how to size the quantity once you know what you need.
Buy, redesign, or both
There are three realistic paths, and most teams end up combining two.
Buy through the last-time-buy date and keep the design. This works when the product has a short remaining life, volumes are low, and the part is dry-pack stable enough to store. It fails when the product life is longer than the stock, when the quantity is hard to forecast, or when NXP does not accept the order in full. It also leaves you with the same problem later, just deferred. Our broader note on microcontroller end-of-life covers the storage and requalification side.
Redesign onto a current part. This is the right answer when the product has years left. The cost is not the chip. It is the firmware port, the board respin if the footprint changes, and retesting.
Buy a bridge, then redesign. Buy enough to cover the redesign schedule plus a margin for a slip, then port without a deadline pressing on every decision. For most small teams this is the sensible default. The buy quantity is set by the schedule, not by the product’s lifetime.
Choosing the replacement
Do not choose a replacement by price or by whichever part is in stock this week. Choose it by how long the vendor commits to making it.
NXP publishes a product longevity program. Its published terms are a minimum availability period for participating products, with a longer period for designated products in some market segments, and the program notes that these can change for reasons outside NXP’s control. The program table is the place to check a candidate part, and some of it requires a sign-in. A longevity listing is a commitment worth weighing, not a guarantee. The Chandler notice itself is a reminder that a site closure can override expectations. Whatever vendor you choose, read the longevity terms for the exact part.
Then work through the technical fit:
- Peripherals. List what the firmware actually uses: timers, ADC channels and resolution, serial ports, PWM, keyboard interrupts, on-chip EEPROM emulation. Map each to the candidate. Differences in ADC reference behavior and timer modes cause the quiet bugs.
- Supply and I/O voltage. Older 5 V designs are common on S08 boards. A candidate that is not 5 V tolerant changes the board, not just the firmware.
- Debug and programming. The programming header, the tools your production line uses, and any bootloader all change with the architecture.
- Package and pinout. Never assume a newer family shares pinout with the old one because the package name matches. Compare each candidate’s package drawing and pin table against your layout, pin by pin.
NXP’s older application note AN4662 covers moving from S08 to the Kinetis L series. It is a Freescale-era document, so check its device references before relying on it, but the way it maps S08 peripherals to Arm Cortex-M peripherals is a useful template for your own mapping. We did not find a current NXP guide that targets S08 specifically. Newer NXP migration notes we found cover moves between 32-bit families, not from S08.
You also do not have to stay with NXP. Moving vendors costs a new toolchain and new peripherals either way, so compare candidates from several vendors on longevity terms and peripheral fit.
Porting the firmware
Moving from an 8-bit part to a 32-bit Arm core is mostly a rewrite of the hardware layer and a retest of the rest. A sound order of work:
- Separate hardware access from logic. If the old code mixes register writes into application logic, pull them behind a thin interface first, on the old part, while you can still run both.
- Capture behavior before you change anything. Record outputs, timing and serial traffic from the working product. These recordings become your regression reference.
- Port peripheral by peripheral. Get a timer tick, then serial, then the ADC, comparing against the recordings at each step.
- Check the timing-sensitive paths. Bit-banged protocols and interrupt-latency assumptions are where an 8-bit design hides surprises.
- Retest at the product level. Run the same functional test the old product passed. If you do not have one, writing it now pays back on every later change.
Keep the old toolchain installed and archived until the port ships. Reproducing a legacy build environment after the fact is its own problem.
How we approach it
We start from your bill of materials and the notice: confirm which lines are actually affected, then size a bridge buy against a realistic redesign schedule. Send us the schematic, the firmware source if you have it, and the exact part numbers from the notice, and we will tell you what we would buy and what we would port.
Sources: the NXP discontinuation notice 202608007DN, the NXP product longevity program, and NXP application note AN4662.
If your product runs on an S08 or similar NXP part, we would check your exact part against the notice and scope a redesign or a buy that fits.
Tools for this topic
- BOM risk checkPaste a bill of materials and get a lifecycle and availability verdict per line before you order.
- ESP32 browser flasherFlash a .bin over USB from the browser. It reads the chip and the file first and refuses firmware built for a different chip, revision or flash size.
- STM32 browser flasherFlash a .dfu, .hex or .bin over USB DFU from the browser. It reads the chip’s flash map and identity first and refuses firmware whose bytes or vector table do not belong on it. Never touches option bytes.
Related notes
- Second-sourcing the SPI flash on a boardA practical review of SPI NOR flash substitutions: check the package, boot path, driver behavior, programming tools, and qualification evidence.
- When your microcontroller goes end-of-lifeWhat an MCU EOL or NRND notice actually means, the four ways to respond, and how to qualify a replacement without a firmware rewrite going sideways.
- Linux board or microcontroller for a new productHow to decide between a Linux compute module and a microcontroller: the tests on power, storage, updates and supply that settle it before layout starts.