Silicon errata before design freeze: check the revision you will ship

A prototype that works on the bench does not establish that every production device carrying the same part number will behave identically. Silicon revisions can have different limitations, and an erratum may depend on a combination of peripheral mode, voltage and firmware sequence that the prototype never exercised.

The useful output of an errata review is a set of design decisions tied to identifiable silicon. A document downloaded into the project folder is only the starting point.

### Identify the device, then the document

Record the complete ordering code, the silicon revision and the version of the errata being reviewed. Do not confuse the errata document’s revision letter with the chip’s revision code. They describe different things.

Manufacturers provide device-specific identification methods. ST’s ES0430 errata for several STM32G4 devices, for example, maps package revision markings Z, Y and X to REV_ID values 0x2001, 0x2002 and 0x2003. Those values occupy the REV_ID field of DBGMCU_IDCODE. Other MCU families use different registers or programming interfaces, so this method must not be copied without checking the relevant documentation.

A production record can capture the revision alongside the serial number and firmware build. That makes it possible to establish which units need a workaround when silicon or software changes.

### Read the triggering condition in full

An issue headed DMA or sleep mode can sound much broader than its actual scope. Microchip’s PIC18(L)F25/26K83 errata, for example, describes DMA transfers that may not work as expected when the CPU is in Doze mode. The affected-revision table is essential to deciding whether that entry applies.

Another entry concerns low-power sleep operation in PIC18F25/26K83 devices between 3.1V and 3.3V. Its documented workaround enables the fixed voltage reference and typically adds 7µA to sleep current. For a battery product, the remedy therefore belongs in the power budget as well as the firmware.

These examples illustrate why the issue title alone is insufficient. The review needs the affected silicon, triggering condition, observed consequence and stated workaround.

A compact review table can use four decisions:

• Applicable: the design uses the affected configuration. • Avoided: an enforced design constraint prevents the trigger. • Mitigated: an implemented workaround has a corresponding test. • Unresolved: applicability or an acceptable remedy still needs evidence.

An unused peripheral can be recorded as avoided, but the reason should survive a later firmware change. Otherwise an innocent-looking feature addition can activate an old limitation.

### Make the workaround testable

Translate each applicable entry into a regression test that reaches the relevant operating state. If the condition involves entering a low-power mode, a normal active-mode functional test will not exercise it. If the workaround changes current consumption, measure that consequence too.

Keep the test, workaround and erratum identifier linked. When an updated chip revision arrives, review that evidence before removing the workaround. ST’s summary tables distinguish limitations with available workarounds from those without them; the presence of an erratum does not imply that firmware can always resolve it.

Before design release, the record should show which silicon was assessed, which conditions were exercised and what remains open. Repeat the comparison when the manufacturer changes the errata or the production silicon, using the original review as the baseline. <p><a href="https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Errata/PIC18-L-F25-26K83-Family-Si-Errata-and-Data-Sheet-Clarifications-DS80000766.pdf">Microchip PIC18(L)F25/26K83 errata</a>. <a href="https://www.st.com/resource/en/errata_sheet/es0430-stm32g471xx473xx474xx483xx484xx-device-errata-stmicroelectronics.pdf">ST STM32G4 ES0430 errata</a>.</p>