Cuando cambia la revisión del chip y no el número de parte

Un distribuidor te envía una notificación de cambio de producto (PCN). El microcontrolador de tu placa va a tener un die nuevo. El número de parte orderable sigue igual, el precio sigue igual, y el aviso dice que la forma, el ajuste y la función no se ven afectados. Entonces un lote construido con inventario nuevo se comporta distinto al lote anterior, y nada en tu lista de materiales (BOM) te dice por qué.

Este es un problema distinto al de una parte que llega a fin de vida. La parte no va a desaparecer. Se está convirtiendo en silencio en otra parte con el mismo nombre, y la carga de demostrar que tu producto sigue funcionando pasa a ser tuya.

Qué cambia realmente un PCN de revisión de die

Los fabricantes revisan el silicio por razones comunes: corregir un erratum, pasar a una nueva fab o proceso, cambiar la metalización, agregar una función a una variante posterior de la familia. STMicroelectronics emitió exactamente este tipo de aviso para el STM32H573 en febrero de 2026, describiendo un rediseño del die en su fab de 300 mm de Crolles y señalando la hoja de errata de la revisión X vigente como la base que el nuevo die mejora (PCN de ST vía Farnell). Es un cambio rutinario y bien ejecutado. Aun así significa que el chip que calificaste no es el chip que vas a recibir.

El reglamento de la industria para estos avisos es JEDEC J-STD-046, antes JESD46, que define qué cuenta como un cambio de forma, ajuste o función y exige avisar al cliente antes del primer envío del producto modificado (JEDEC J-STD-046). La política publicada de Microchip es un buen ejemplo de cómo lo interpretan los fabricantes: la notificación cubre cambios en la hoja de datos, en la errata y en las revisiones de die de silicio, pero el fabricante se reserva el derecho de hacer cambios sin aviso cuando la forma, el ajuste y la función no se ven afectados (política de PCN y EOL de Microchip). Las palabras “no se ven afectados” son un juicio del proveedor, hecho contra la hoja de datos. Tu firmware puede depender de un comportamiento que la hoja de datos nunca prometió.

Los dos casos que muerden en la práctica:

• Se corrige un erratum para el que tenías un workaround. Un workaround que limpia una bandera atascada, reintenta un periférico o retrasa un cambio de reloj puede comportarse mal cuando el bug de fondo desaparece. Los workarounds rara vez se escriben para verificar si todavía hacen falta.
• Un periférico gana un modo o cambia un valor por defecto. La revisión del STM32H7 que llevó a la familia del silicio temprano Y a la revisión V agregó un divisor en la ruta del reloj del ADC y cambió la secuencia de programación de la flash, con el número de parte sin cambios. Ingenieros del foro de EEVblog encontraron configuraciones de reloj del ADC existentes funcionando a la mitad de la velocidad prevista en los chips nuevos (hilo de EEVblog). El código de pedido no daba ninguna advertencia.

Los fabricantes manejan los nombres de manera distinta, y la diferencia importa al comprar. Silicon Labs cambió el número de parte orderable cuando lanzó la revisión C del EFR32FG23 y el EFR32ZG23, pasando el sufijo de -BR a -CR, de modo que una orden de compra puede especificar qué die quiere (Silicon Labs PCN 2206211261). ST y Microchip por lo general conservan el número y registran la revisión en la hoja de errata. Ninguno está mal, pero solo uno de los dos le permite a un comprador filtrar el inventario.

Cómo encontrar la revisión que tienes

Toda familia seria de microcontroladores expone su revisión de die en un registro, y la hoja de errata es el decodificador.

Familia	Dónde está la revisión	Dónde se decodifica
STM32	DBGMCU_IDCODE, REV_ID en los bits 31:16, DEV_ID en los bits 11:0 (H7 llama al registro DBGMCU IDC)	La hoja de errata del dispositivo lista el valor de REV_ID de cada revisión
Microchip SAM D5x/E5x	Registro DID de la Device Service Unit	El documento de errata de silicio de la familia tabula los problemas por revisión
Nordic nRF52	FICR INFO.VARIANT contiene el código de build	Cada documento de errata se publica por código de build

Vale la pena copiar el formato de errata de Microchip en tu propio seguimiento: una tabla, un renglón por problema, una columna por revisión, con una marca donde el problema está presente y un espacio en blanco donde fue corregido (errata de silicio del SAM D5x/E5x). Lee hacia abajo la columna de la revisión que probaste y la de la revisión que estás por recibir. Cada renglón que difiere es un punto de revisión para el firmware.

Dos precauciones de campo. Primera, la documentación va detrás del silicio. Un desarrollador que leyó el registro de revisión de un STM32U5A5 a finales de 2025 obtuvo un valor que no aparecía en el manual de referencia; ST confirmó que era una revisión W más nueva y que el manual y la errata se actualizarían más adelante (hilo de la comunidad de ST). Un firmware que trata una revisión desconocida como un error se inutilizará a sí mismo en partes perfectamente buenas. Regístrala, no te detengas por ella.

Segunda, el marcado del encapsulado no sustituye de forma confiable al registro. Los encapsulados más nuevos de ST eliminaron la letra de revisión impresa y el logotipo de Arm a favor de un código QR, y la revisión del die ahora es un pequeño carácter aparte que requiere el diagrama de marcado de la hoja de datos para leerse (hilo de la comunidad de ST sobre el marcado del F429). Un código de fecha te dice cuándo se ensambló, no qué die hay dentro. Si la revisión importa, léela eléctricamente.

Lo más barato que puedes hacer hoy, antes de que llegue cualquier PCN, es hacer que el firmware lea el registro de revisión al arrancar y lo imprima en la consola de depuración y en el log del dispositivo. Así la primera unidad construida con silicio nuevo te lo avisa, en lugar de un cliente.

Qué recalificar

El aviso dirá que se hicieron pruebas y que el cambio es transparente. Tómalo como una afirmación sobre la hoja de datos, y luego corre tu propia lista:

1. Compara las hojas de errata. La columna de la revisión anterior contra la nueva. Cada erratum corregido es un workaround que inspeccionar. Cada erratum nuevo es un comportamiento que probar. Cada bit de registro “reserved” que antes hacía algo es un lugar donde tu código puede estar escribiendo.
2. Busca en el firmware código específico de revisión. El código de HAL y SDK del fabricante muchas veces se bifurca según el ID de revisión. Confirma que la versión de tu toolchain conoce el nuevo valor. Las propias bibliotecas del fabricante pueden ser lo que se rompa.
3. Vuelve a correr las pruebas de periféricos que tocan lo analógico o los tiempos. Precisión y tasa de muestreo del ADC, ajuste del oscilador interno, corriente en bajo consumo, umbrales de brownout, tiempos de escritura en flash. Ahí es donde los cambios de die salen a la superficie primero, y son lo más difícil de notar con una prueba funcional que solo verifica que “arranca y se comunica”.
4. Vuelve a correr el flujo de programación y aprovisionamiento de producción. Una secuencia de programación de flash modificada o un nuevo valor por defecto de los option bytes pueden poner en rojo un fixture que estaba en verde sin ningún cambio de firmware.
5. Vigila la corriente en reposo. Los cambios de proceso modifican las fugas. Un producto que cumplía su especificación de duración de batería con el die anterior merece una medición nueva con el nuevo.

El costo en tiempo es sobre todo lectura y una corrida corta de regresión. El costo en riesgo es asimétrico: una hora de revisión de errata es barata, y una devolución de campo causada por un workaround que ahora se dispara dos veces no lo es.

Comprar la revisión que probaste

Cuando el código de pedido no cambia, los distribuidores no pueden filtrar por ti. A un comprador de un Microchip SAM E53 que preguntó en el foro de un distribuidor qué revisión había en inventario le dijeron que no hay forma de saberlo por el número de parte, y el consejo práctico fue llamar, agregar una nota a la orden y pedir que alguien revise el reel (hilo del foro de DigiKey). Eso funciona para una corrida pequeña. No es una cadena de suministro.

Mejores opciones, en orden de cuánto control te dan:

• Compra toda la corrida de una vez de un solo lote cuando la producción es pequeña, de modo que todas las placas del lote lleven el mismo die, y registra en el historial de construcción la revisión leída de una muestra.
• Pide al fabricante la correspondencia entre revisión y código de fecha. Algunos fabricantes darán un código de fecha aproximado a partir del cual solo se envía el die nuevo. Tómalo como una guía, no como una garantía.
• Haz que el firmware sea indiferente. Si la diferencia entre errata es pequeña, la posición más sólida es un código que corra correctamente en ambas revisiones e informe cuál encontró. Así la orden de compra puede seguir siendo simple y el riesgo vive en una prueba que ya corres.
• Registra la revisión en las notas de la BOM, no solo el número de parte. Cuando llegue el siguiente PCN, querrás saber en una sola consulta qué die usó cada lote enviado.

El cambio de mentalidad es pequeño: un número de parte identifica una familia de dice compatibles, no una pieza fija de silicio. Todo diseño debería llevar ya una lectura de revisión al arrancar, una copia de la hoja de errata contra la que se calificó y una lista corta de regresión que pueda correrse cuando llegue el siguiente aviso.

Leemos el aviso y la diferencia de errata, revisamos el firmware en busca de workarounds obsoletos y bifurcaciones por revisión, y corremos las pruebas de periféricos afectados con el inventario nuevo antes de que entre a una construcción. Envíanos el PCN, el firmware actual y la hoja de errata de la parte.