{"id":2482,"date":"2026-09-02T21:19:12","date_gmt":"2026-09-03T03:19:12","guid":{"rendered":"https:\/\/sbcgroup.com.mx\/?p=2482"},"modified":"2026-09-02T21:19:13","modified_gmt":"2026-09-03T03:19:13","slug":"verificacion-post-programacion-ics-crc-readback","status":"publish","type":"post","link":"https:\/\/sbcgroup.com.mx\/en\/2026\/09\/02\/verificacion-post-programacion-ics-crc-readback\/","title":{"rendered":"How to Validate Firmware and Configuration After Programming an IC"},"content":{"rendered":"\n

Validaci\u00f3n Firmware y Configuraci\u00f3n Despu\u00e9s de Programar un IC<\/h1>\n\n\n\n

En una estaci\u00f3n de programaci\u00f3n, la palabra PASS<\/strong> suele interpretarse como una confirmaci\u00f3n definitiva: el firmware fue cargado y el circuito integrado est\u00e1 listo para producci\u00f3n. Sin embargo, ese resultado s\u00f3lo demuestra que la receta ejecut\u00f3 determinados pasos sin detectar una condici\u00f3n de falla. No necesariamente confirma que se utiliz\u00f3 la imagen correcta, que el mapa de memoria fue interpretado correctamente, que los fuses quedaron en el estado esperado o que el dispositivo podr\u00e1 arrancar cuando se retire el programador.<\/p>\n\n\n\n

La verificaci\u00f3n post-programaci\u00f3n debe responder una pregunta m\u00e1s amplia: \u00bfesta unidad contiene el firmware, la identidad y la configuraci\u00f3n correctos, y puede cumplir su funci\u00f3n m\u00ednima en condiciones reales de arranque?<\/strong> Para contestarla se combinan m\u00e9todos con coberturas diferentes: verify durante el proceso, readback, checksum, CRC, hash criptogr\u00e1fico, firma digital, lectura de configuraci\u00f3n y prueba funcional.<\/p>\n\n\n\n

Ning\u00fan m\u00e9todo individual cubre todos los riesgos. Una comparaci\u00f3n byte a byte puede confirmar contenido, pero no demuestra que la unidad arranque. Un CRC puede detectar cambios con rapidez, pero no autentica al autor del firmware. Una prueba funcional puede confirmar comunicaci\u00f3n y consumo, aunque podr\u00eda ejecutarse sobre una revisi\u00f3n equivocada si no se valida el identificador de la imagen. El control de calidad surge de la combinaci\u00f3n de capas independientes.<\/p>\n\n\n\n

Programar no es validar: qu\u00e9 puede ocultar un \u201cPASS\u201d<\/h2>\n\n\n\n
\"Infograf\u00eda<\/figure>\n\n\n\n

El primer riesgo es la referencia equivocada<\/strong>. El archivo puede ser t\u00e9cnicamente v\u00e1lido y programarse sin errores, pero corresponder a otra revisi\u00f3n de hardware, mercado o variante de producto. La estaci\u00f3n informar\u00e1 PASS porque escribi\u00f3 exactamente lo que se le solicit\u00f3; el defecto est\u00e1 en la selecci\u00f3n de la receta.<\/p>\n\n\n\n

El segundo riesgo es una interpretaci\u00f3n compartida incorrecta<\/strong>. Keysight documenta que las rutinas de Program y Verify pueden utilizar el mismo registro de datos. Si ambas interpretan de manera equivocada la fuente, el verify puede aprobar un contenido incorrecto. La compa\u00f1\u00eda recomienda un CRC independiente del registro de programaci\u00f3n, siempre que el valor de referencia provenga de una unidad conocida como correcta.[1<\/a>]<\/p>\n\n\n\n

Tambi\u00e9n puede existir un alcance incompleto<\/strong>. Una operaci\u00f3n verifica solamente las direcciones presentes en el archivo, pero deja sin revisar otras regiones del dispositivo. All\u00ed podr\u00edan permanecer datos de una programaci\u00f3n anterior, valores de calibraci\u00f3n incorrectos o contenido inesperado. En otros casos, el firmware se compara correctamente, pero los option bytes, fuses, lock bits o p\u00e1ginas OTP quedan fuera de la validaci\u00f3n.<\/p>\n\n\n\n

Modo de falla oculto<\/th>Por qu\u00e9 puede existir un PASS<\/th>Control complementario<\/th><\/tr><\/thead>
Revisi\u00f3n de firmware equivocada<\/td>La imagen es grabable y coincide con el archivo seleccionado<\/td>Validar n\u00famero de parte, variante y manifiesto de liberaci\u00f3n<\/td><\/tr>
Offset o mapa mal interpretado<\/td>Program y Verify comparten la misma fuente incorrecta<\/td>CRC o hash independiente y prueba de arranque<\/td><\/tr>
Datos residuales fuera de la imagen<\/td>Verify cubre s\u00f3lo los rangos definidos<\/td>CRC del dispositivo completo o lectura de regiones reservadas<\/td><\/tr>
Fuses u option bytes incorrectos<\/td>La Flash principal coincide<\/td>Readback de configuraci\u00f3n despu\u00e9s de power cycle<\/td><\/tr>
Lock bit no aplicado<\/td>El contenido es correcto pero queda expuesto<\/td>Lectura final del estado de protecci\u00f3n<\/td><\/tr>
Problema de arranque o alimentaci\u00f3n<\/td>La interfaz de programaci\u00f3n mantiene condiciones especiales<\/td>Prueba funcional sin depurador y con reset real<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Qu\u00e9 comprueba cada m\u00e9todo de verificaci\u00f3n<\/h2>\n\n\n\n
\"Comparaci\u00f3n<\/figure>\n\n\n\n

Los t\u00e9rminos verify, readback, checksum, CRC y hash suelen usarse como si fueran equivalentes. No lo son. Cada uno transforma el problema de validaci\u00f3n de forma diferente, con distintas probabilidades de detectar un error, necesidades de tiempo y propiedades de seguridad.<\/p>\n\n\n\n

Verify durante la programaci\u00f3n<\/h3>\n\n\n\n

El verify tradicional lee cada celda, palabra o bloque y lo compara con el archivo objeto. Es la comprobaci\u00f3n m\u00e1s directa para detectar bytes diferentes dentro del rango programado. PEmicro describe esta comparaci\u00f3n byte a byte como el mecanismo habitual y diferencia esa verificaci\u00f3n de los m\u00e9todos basados en CRC.[2<\/a>]<\/p>\n\n\n\n

Su principal fortaleza es la localizaci\u00f3n: puede indicar la direcci\u00f3n exacta del primer mismatch. Su l\u00edmite es el alcance definido por la receta. Si el proyecto omite una regi\u00f3n o espera err\u00f3neamente datos en otra direcci\u00f3n, el verify no corrige ese error de ingenier\u00eda.<\/p>\n\n\n\n

Readback<\/h3>\n\n\n\n

El readback extrae el contenido del IC y lo guarda o transmite para an\u00e1lisis independiente. Puede compararse con la imagen maestra, utilizarse para investigar una unidad fallada o conservarse como evidencia de primera pieza. Su ventaja es separar la adquisici\u00f3n del an\u00e1lisis; su costo es el tiempo de lectura y el manejo seguro de informaci\u00f3n sensible.<\/p>\n\n\n\n

El readback no siempre est\u00e1 disponible. La protecci\u00f3n de lectura puede bloquearlo despu\u00e9s de aplicar lock bits y algunos dispositivos s\u00f3lo permiten acceder a zonas concretas. Por ello, si el plan requiere evidencia de lectura, debe ejecutarse antes<\/strong> de la protecci\u00f3n irreversible. Adem\u00e1s, los archivos extra\u00eddos deben controlarse como propiedad intelectual y eliminarse de estaciones temporales cuando termina el an\u00e1lisis.<\/p>\n\n\n\n

Checksum y CRC<\/h3>\n\n\n\n

Un checksum aritm\u00e9tico resume los datos mediante una operaci\u00f3n sencilla. Puede detectar muchos errores comunes, pero ofrece menos capacidad de detecci\u00f3n que un CRC bien seleccionado. El CRC<\/strong> aplica una divisi\u00f3n polin\u00f3mica y est\u00e1 dise\u00f1ado para identificar alteraciones accidentales, incluidos patrones de errores en r\u00e1faga. Para que el resultado sea comparable, deben coincidir el polinomio, valor inicial, reflexi\u00f3n, XOR final, rango de direcciones y orden de bytes.<\/p>\n\n\n\n

PEmicro documenta verificaciones CRC-16 sobre las direcciones presentes en el archivo y sobre el dispositivo completo. La segunda puede detectar contenido inesperado incluso en regiones no programadas por el objeto. Tambi\u00e9n puede ser m\u00e1s r\u00e1pida que una comparaci\u00f3n byte a byte cuando el enlace de depuraci\u00f3n es lento.[2<\/a>]<\/p>\n\n\n\n

Un CRC no prueba autenticidad y tampoco es invulnerable a una modificaci\u00f3n deliberada. Su valor en producci\u00f3n es detectar corrupci\u00f3n accidental de manera eficiente. El valor esperado debe calcularse desde el artefacto maestro aprobado; \u201caprender\u201d el CRC de una unidad no validada puede convertir un defecto en nueva referencia.<\/p>\n\n\n\n

Hash criptogr\u00e1fico y firma digital<\/h3>\n\n\n\n

Un hash como SHA-256 genera un digest que cambia cuando se modifica el mensaje. NIST FIPS 180-4 define algoritmos hash seguros cuyos digests se utilizan para detectar si los mensajes han cambiado desde que fueron calculados.[3<\/a>] En un proceso de manufactura, el hash puede vincular el archivo liberado, la receta del programador y el contenido le\u00eddo del dispositivo.<\/p>\n\n\n\n

El hash confirma igualdad contra una referencia confiable, pero no acredita qui\u00e9n autoriz\u00f3 la imagen. La firma digital a\u00f1ade autenticaci\u00f3n del origen, integridad y no repudio cuando se implementa correctamente, seg\u00fan la definici\u00f3n de NIST.[4<\/a>] Por ello, CRC y hash atienden principalmente integridad; la firma digital atiende integridad y autenticidad.<\/p>\n\n\n\n

\"Comparativa<\/figure>\n\n\n\n
M\u00e9todo<\/th>Qu\u00e9 comprueba<\/th>Fortaleza<\/th>L\u00edmite principal<\/th><\/tr><\/thead>
Verify<\/td>Igualdad byte a byte en rangos definidos<\/td>Localiza la direcci\u00f3n de la diferencia<\/td>Depende de que archivo, offset y rango sean correctos<\/td><\/tr>
Readback<\/td>Contenido realmente legible del IC<\/td>Permite an\u00e1lisis independiente<\/td>Puede bloquearse por seguridad y expone IP<\/td><\/tr>
Checksum<\/td>Resumen aritm\u00e9tico<\/td>Simple y r\u00e1pido<\/td>Menor capacidad de detecci\u00f3n<\/td><\/tr>
CRC<\/td>Corrupci\u00f3n accidental en un rango definido<\/td>Buena detecci\u00f3n y ejecuci\u00f3n eficiente<\/td>No autentica el origen<\/td><\/tr>
SHA-256<\/td>Integridad contra un digest maestro<\/td>Resistencia criptogr\u00e1fica<\/td>Sin firma no prueba autor\u00eda<\/td><\/tr>
Firma digital<\/td>Integridad y autenticidad del origen<\/td>Permite cadena de confianza<\/td>Exige gesti\u00f3n segura de llaves<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Validaci\u00f3n de fuses, option bytes, lock bits y datos \u00fanicos<\/h2>\n\n\n\n
\"Secuencia<\/figure>\n\n\n\n

El firmware no es la \u00fanica informaci\u00f3n que define el comportamiento de un IC. En diferentes familias, la configuraci\u00f3n no vol\u00e1til puede seleccionar la fuente de reloj, el watchdog, el modo de arranque, la protecci\u00f3n de lectura, la protecci\u00f3n de escritura, el brownout, el debug y la distribuci\u00f3n de memoria.<\/p>\n\n\n\n

ST explica que los option bytes se encuentran en una regi\u00f3n diferente de la Flash de usuario y pueden cargarse despu\u00e9s de un power-on reset o mediante un mecanismo espec\u00edfico. Un reset de software o la se\u00f1al NRST no necesariamente hace efectivos los nuevos valores. La validaci\u00f3n debe leer la configuraci\u00f3n cargada en el dispositivo, no limitarse a confirmar que termin\u00f3 la escritura.[5<\/a>]<\/p>\n\n\n\n

Microchip se\u00f1ala que los fuses AVR definen configuraciones de hardware como reloj, watchdog y debug; una selecci\u00f3n incorrecta puede dejar al MCU no programable o no depurable en la aplicaci\u00f3n. Tambi\u00e9n advierte que ciertos lock bits impiden modificar los fuses, por lo que el orden correcto es programar y verificar la configuraci\u00f3n antes de aplicar el bloqueo.[6<\/a>]<\/p>\n\n\n\n

La misma disciplina aplica a n\u00fameros de serie, direcciones MAC, certificados, llaves y calibraciones. Cada valor debe tener un origen autorizado, un rango v\u00e1lido y una relaci\u00f3n inequ\u00edvoca con la unidad. La estaci\u00f3n debe verificar que el identificador no est\u00e9 duplicado, que la escritura ocurra en la direcci\u00f3n prevista y que el readback coincida antes de confirmar el consumo del valor en la base de datos.<\/p>\n\n\n\n

Prueba funcional m\u00ednima despu\u00e9s de programar<\/h2>\n\n\n\n
\"Prueba<\/figure>\n\n\n\n

La prueba funcional no pretende sustituir al ICT, al test de sistema ni a la validaci\u00f3n de dise\u00f1o. Su objetivo es demostrar que el IC programado inicia en condiciones representativas y que las funciones esenciales para continuar la manufactura est\u00e1n disponibles.<\/p>\n\n\n\n

El primer paso es retirar las condiciones especiales de programaci\u00f3n. El depurador debe liberar reset, los boot pins deben adoptar su estado de producto y la alimentaci\u00f3n debe ciclarse cuando la configuraci\u00f3n se carga en power-on. Esto evita aprobar una unidad que s\u00f3lo funciona mientras el programador sostiene una se\u00f1al o mantiene activo un dominio de energ\u00eda.<\/p>\n\n\n\n

\"Diagrama<\/figure>\n\n\n\n
Prueba m\u00ednima<\/th>Qu\u00e9 confirma<\/th>Ejemplo de criterio<\/th><\/tr><\/thead>
Reset \/ power cycle<\/td>Secuencia real de arranque y carga de configuraci\u00f3n<\/td>Arranque limpio en cada uno de tres ciclos<\/td><\/tr>
Identidad de firmware<\/td>Versi\u00f3n, variante y compilaci\u00f3n correctas<\/td>Respuesta exacta del comando de versi\u00f3n<\/td><\/tr>
Comunicaci\u00f3n b\u00e1sica<\/td>CPU, reloj, firmware y transceptor funcionales<\/td>Handshake por UART, CAN, USB o Ethernet<\/td><\/tr>
Corriente<\/td>Ausencia de corto, bloqueo o modo incorrecto<\/td>Ventana definida para reposo y actividad<\/td><\/tr>
Memoria y configuraci\u00f3n<\/td>Acceso a Flash\/EEPROM y par\u00e1metros v\u00e1lidos<\/td>Autoprueba o lectura de firma interna<\/td><\/tr>
Perif\u00e9rico cr\u00edtico<\/td>Camino indispensable para la siguiente estaci\u00f3n<\/td>Sensor, salida, radio o interfaz de seguridad<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Los l\u00edmites deben definirse por producto y validarse estad\u00edsticamente; no conviene copiar una ventana de corriente gen\u00e9rica. Una medici\u00f3n demasiado amplia no detectar\u00e1 anomal\u00edas y una demasiado estrecha puede rechazar variaci\u00f3n normal de componentes, temperatura o tolerancia de la fuente.<\/p>\n\n\n\n

Resultados y trazabilidad: qu\u00e9 registrar<\/h2>\n\n\n\n
\"Registros<\/figure>\n\n\n\n

El registro de un PASS debe permitir reconstruir qu\u00e9 ocurri\u00f3 sin depender de la memoria del operador. IPC identifica IPC-1782 como el est\u00e1ndar de trazabilidad para manufactura y cadena de suministro de productos electr\u00f3nicos.[7<\/a>] El nivel de detalle requerido depende del riesgo del producto, pero la asociaci\u00f3n entre unidad, proceso y resultado debe ser inequ\u00edvoca.<\/p>\n\n\n\n

Por unidad, conviene registrar el UID o serial, n\u00famero de parte y revisi\u00f3n del IC, JEDEC ID o device ID, nombre y hash de la imagen, receta y versi\u00f3n del algoritmo, valores de configuraci\u00f3n, seriales o calibraciones inyectadas, resultado de verify, CRC o hash le\u00eddo, resultado funcional, c\u00f3digo de falla, equipo, fixture, operador o sesi\u00f3n autorizada y sello de tiempo.<\/p>\n\n\n\n

Por lote deben conservarse la orden de trabajo, lote del semiconductor, cantidad recibida, programada, aprobada, rechazada y pendiente, cambios de receta, primera pieza, golden sample utilizada y liberaci\u00f3n de calidad. El registro debe ser inmutable o mantener historial de cambios; corregir un dato no debe eliminar el valor anterior ni la identidad de quien realiz\u00f3 la modificaci\u00f3n.<\/p>\n\n\n\n

Gesti\u00f3n de fallas, cuarentena y l\u00edmites de reprogramaci\u00f3n<\/h2>\n\n\n\n
\"Flujo<\/figure>\n\n\n\n

Una unidad con mismatch, configuraci\u00f3n inesperada o falla funcional no debe volver autom\u00e1ticamente al inicio del ciclo. El reintento indiscriminado puede convertir una falla intermitente de fixture en un PASS aparente, borrar evidencia diagn\u00f3stica o consumir ciclos de escritura sin resolver la causa.<\/p>\n\n\n\n

El flujo correcto comienza con cuarentena f\u00edsica y l\u00f3gica<\/strong>. Deben preservarse el c\u00f3digo de error, el paso donde ocurri\u00f3, voltajes, corriente, readback permitido, n\u00famero de socket y estado del fixture. Despu\u00e9s se clasifica la causa probable: archivo o receta, dispositivo, contacto mec\u00e1nico, alimentaci\u00f3n, integridad de se\u00f1al, bloqueo de seguridad o falla del ensamble.<\/p>\n\n\n\n

La reprogramaci\u00f3n puede autorizarse cuando el dispositivo permanece accesible, no se aplicaron protecciones irreversibles, los datos \u00fanicos no han sido consumidos de forma inconsistente y el l\u00edmite de retrabajo est\u00e1 definido. Debe prohibirse cuando exista identidad duplicada, evidencia de da\u00f1o el\u00e9ctrico, lock irreversible incorrecto o trazabilidad incompleta. Cada retrabajo debe crear un nuevo evento, nunca sustituir el registro original.<\/p>\n\n\n\n

Ejemplo de plan de control para un lote de producci\u00f3n<\/h2>\n\n\n\n
\"Ejemplo<\/figure>\n\n\n\n

El siguiente ejemplo presenta una estructura adaptable para un lote de microcontroladores con firmware, option bytes y serializaci\u00f3n. No reemplaza el datasheet, la especificaci\u00f3n del producto ni el plan de calidad aprobado.<\/p>\n\n\n\n

Etapa<\/th>Caracter\u00edstica<\/th>M\u00e9todo<\/th>Frecuencia<\/th>Reacci\u00f3n ante falla<\/th><\/tr><\/thead>
Liberaci\u00f3n<\/td>Archivo, versi\u00f3n y SHA-256<\/td>Comparar contra manifiesto firmado<\/td>Cada revisi\u00f3n<\/td>Bloquear receta<\/td><\/tr>
Setup<\/td>Dispositivo, algoritmo y voltaje<\/td>Leer device ID y validar receta<\/td>Cada cambio de lote o setup<\/td>STOP y revisi\u00f3n de ingenier\u00eda<\/td><\/tr>
Primera pieza<\/td>Flash, configuraci\u00f3n y arranque<\/td>Verify completo, readback, hash y prueba funcional<\/td>Primera unidad y despu\u00e9s de ajuste<\/td>Cuarentena del setup completo<\/td><\/tr>
Producci\u00f3n<\/td>Contenido programado<\/td>Verify byte a byte o CRC aprobado<\/td>100% de unidades<\/td>Segregar unidad y socket<\/td><\/tr>
Producci\u00f3n<\/td>Fuses, option bytes y serial<\/td>Lectura posterior y comparaci\u00f3n<\/td>100% de unidades<\/td>Bloquear retrabajo autom\u00e1tico<\/td><\/tr>
Funcional<\/td>Reset, versi\u00f3n, comunicaci\u00f3n y corriente<\/td>Fixture de prueba m\u00ednima<\/td>100% o frecuencia basada en riesgo<\/td>Cuarentena y diagn\u00f3stico<\/td><\/tr>
Auditor\u00eda<\/td>Contenido fuera del rango de imagen<\/td>CRC del dispositivo completo o readback<\/td>Muestreo por lote y cambio<\/td>Contenci\u00f3n del lote<\/td><\/tr>
Cierre<\/td>Balance y registros<\/td>Reconciliaci\u00f3n MES<\/td>Cada lote<\/td>No liberar embarque<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

En productos cr\u00edticos, los cambios de firmware, algoritmo, fixture, socket o fuente de alimentaci\u00f3n deben disparar una nueva primera pieza. Las tendencias de fallas por socket y por estaci\u00f3n tambi\u00e9n deben revisarse: una tasa creciente de retries puede anticipar desgaste antes de que aparezcan rechazos permanentes.<\/p>\n\n\n\n

Una estrategia de validaci\u00f3n por capas<\/h2>\n\n\n\n
\"Modelo<\/figure>\n\n\n\n

La forma m\u00e1s robusta de evitar unidades \u201caparentemente programadas\u201d es separar las preguntas de calidad. Primero se confirma la identidad del IC. Despu\u00e9s se verifica el contenido dentro y fuera de los rangos relevantes. Luego se leen la configuraci\u00f3n y los datos \u00fanicos. Finalmente se prueba el comportamiento despu\u00e9s de un reset real.<\/p>\n\n\n\n

Esta independencia reduce los puntos ciegos. Si Program y Verify comparten una interpretaci\u00f3n err\u00f3nea, un hash independiente o el boot test puede detectar la discrepancia. Si el contenido es correcto pero los fuses son incorrectos, la lectura posterior y el power cycle revelan el problema. Si todos los valores son correctos pero el hardware no inicia, la prueba funcional evita que la unidad avance.<\/p>\n\n\n\n

El objetivo no es acumular pruebas por rutina, sino dise\u00f1ar una cobertura proporcional al riesgo, con referencias maestras controladas, l\u00edmites claros y una reacci\u00f3n definida. En producci\u00f3n electr\u00f3nica, la calidad del firmware no termina al escribir el \u00faltimo byte; termina cuando la unidad demuestra que contiene, protege y ejecuta la configuraci\u00f3n correcta<\/strong>.<\/p>\n\n\n\n

Conoce m\u00e1s<\/h2>\n\n\n\n