When a chip revision changes but the part number doesn't

A product change notification lands from a distributor. The microcontroller on your board is getting a new die. The orderable part number stays the same, the price stays the same, and the notice says form, fit and function are unaffected. Then a batch built from new stock behaves differently from the batch before it, and nothing in your bill of materials tells you why.

This is a distinct problem from a part going end-of-life. The part is not going away. It is quietly becoming a different part with the same name, and the burden of proving your product still works moves onto you.

What a die-revision PCN actually changes

Vendors revise silicon for ordinary reasons: fix an erratum, move to a new fab or process, change metallization, add a feature to a later variant of the family. STMicroelectronics issued exactly this kind of notice for the STM32H573 in February 2026, describing a die redesign at its Crolles 300 mm fab and pointing at the errata sheet for the current revision X as the baseline the new die improves on (ST PCN via Farnell). That is a routine, well-run change. It still means the chip you qualified is not the chip you will receive.

The industry rulebook for these notices is JEDEC J-STD-046, formerly JESD46, which defines what counts as a change to form, fit or function and calls for customer notice before the first shipment of the changed product (JEDEC J-STD-046). Microchip’s published policy is a good example of how vendors read it: notification covers datasheet, errata and silicon die revisions, but the vendor reserves the right to make changes without notice when form, fit and function are not affected (Microchip PCN and EOL policy). The words “not affected” are a judgment made by the supplier, against the datasheet. Your firmware may depend on behavior the datasheet never promised.

The two cases that bite in practice:

• An erratum you worked around gets fixed. A workaround that clears a stuck flag, retries a peripheral or delays a clock switch can misbehave when the underlying bug disappears. Workarounds are rarely written to check whether they are still needed.
• A peripheral gains a mode or a default changes. The STM32H7 revision that moved the family from its early Y silicon to revision V added a divider in the ADC clock path and changed the flash programming sequence, with the part number unchanged. Engineers on the EEVblog forum found existing ADC clock configurations running at half the intended rate on the new chips (EEVblog thread). The ordering code gave no warning.

Vendors handle the naming differently, and the difference matters when you buy. Silicon Labs changed the orderable part number when it released revision C of the EFR32FG23 and EFR32ZG23, moving the suffix from -BR to -CR, so a purchase order can specify which die it wants (Silicon Labs PCN 2206211261). ST and Microchip generally keep the number and track the revision in the errata sheet. Neither is wrong, but only one of them lets a buyer filter stock.

Finding the revision you have

Every serious microcontroller family exposes its die revision in a register, and the errata sheet is the decoder ring.

Family	Where the revision lives	Where it is decoded
STM32	DBGMCU_IDCODE, REV_ID in bits 31:16, DEV_ID in bits 11:0 (H7 calls the register DBGMCU IDC)	The device errata sheet lists the REV_ID value for each revision
Microchip SAM D5x/E5x	Device Service Unit DID register	The family silicon errata document tables issues per revision
Nordic nRF52	FICR INFO.VARIANT holds the build code	Each errata document is published per build code

Microchip’s errata format is worth copying into your own tracking: one table, one row per issue, one column per revision, with a mark where the issue is present and a blank where it has been fixed (SAM D5x/E5x silicon errata). Read down the column for the revision you tested and the revision you are about to receive. Every row that differs is a firmware review item.

Two cautions from the field. First, documentation lags silicon. A developer reading the revision register on an STM32U5A5 in late 2025 got a value that did not appear in the reference manual at all; ST confirmed it was a newer revision W and that the manual and errata would be updated later (ST community thread). Firmware that treats an unknown revision as an error will brick itself on perfectly good parts. Log it, do not halt on it.

Second, the package marking is not a reliable substitute for the register. Newer ST packages dropped the printed revision letter and the Arm logo in favor of a QR code, and the die revision is now a small separate character that needs the datasheet’s marking diagram to read (ST community thread on F429 marking). A date code tells you when it was assembled, not which die is inside. If the revision matters, read it electrically.

The cheapest thing you can do today, before any PCN arrives, is have firmware read the revision register at boot and print it on the debug console and into the device log. Then the first unit built on new silicon tells you so, instead of a customer.

What to requalify

The notice will say testing was performed and the change is transparent. Treat that as a claim about the datasheet, then run your own list:

1. Diff the errata sheets. Old revision column against new. Every fixed erratum is a workaround to inspect. Every new erratum is a behavior to test. Every “reserved” register bit that used to do something is a place your code may be writing.
2. Grep the firmware for revision-specific code. Vendor HAL and SDK code often branches on the revision ID. Confirm your toolchain version knows about the new value. The vendor’s own libraries can be the thing that breaks.
3. Re-run the peripheral tests that touch analog or timing. ADC accuracy and sample rate, internal oscillator trim, low-power current, brown-out thresholds, flash write timing. These are where die changes surface first, and they are the hardest to notice from a functional test that only checks “it boots and talks.”
4. Re-run the production programming and provisioning flow. A changed flash programming sequence or a new option-byte default can turn a green fixture red with no firmware change at all.
5. Watch the sleep current. Process moves change leakage. A product that met its battery-life spec on the old die deserves a fresh measurement on the new one.

Time cost is mostly reading and a short regression run. Risk cost is asymmetric: an hour of errata review is cheap, and a field return caused by a workaround that now double-fires is not.

Buying the revision you tested

When the ordering code does not change, distributors cannot filter for you. A Microchip SAM E53 buyer asking a distributor’s forum which revision was in stock was told there is no way to tell from the part number, and the practical advice was to call, add a note to the order, and have someone check the reel (DigiKey forum thread). That works for a small run. It is not a supply chain.

Better options, in order of how much control they give you:

• Buy the whole run at once from a single lot when the build is small, so every board in the batch carries the same die, and record the revision read from a sample in the build record.
• Ask the vendor for the revision-to-date-code mapping. Some vendors will provide an approximate date code after which only the new die ships. Treat it as a guide, not a guarantee.
• Make the firmware indifferent. If the errata diff is small, the strongest position is code that runs correctly on both revisions and reports which one it found. Then the purchase order can stay simple and the risk lives in a test you already run.
• Track the revision in the BOM notes, not just the part number. When the next PCN arrives, you want to know in one lookup which die every shipped batch used.

The mindset change is small: a part number identifies a family of compatible dice, not a fixed piece of silicon. Every design should already carry a revision-read at boot, a copy of the errata sheet it was qualified against, and a short regression list that can be run when the next notice arrives.

We read the notice and the errata diff, check the firmware for stale workarounds and revision branches, and run the affected peripheral tests on new stock before it goes into a build. Send us the PCN, the current firmware and the part’s errata sheet.