Aprovisionar números de serie en la línea

El prototipo funciona. Luego sale de la línea el primer lote pequeño y todas las placas son idénticas: el mismo firmware, sin número de serie, sin llaves y con el puerto de depuración completamente abierto. La aplicación móvil no puede distinguir una unidad de otra, el lado de la nube no tiene nada que autenticar, y la pregunta que era fácil de posponer ahora bloquea el envío: ¿qué se escribe en cada placa, en qué orden y cómo demostramos que sucedió?

Este es el paso de aprovisionamiento, y pertenece al diseño, no a un script apresurado la semana antes del ensamblaje. Las tres familias de microcontroladores que vemos con más frecuencia, STM32, Nordic nRF52 y Espressif ESP32, ofrecen cada una un identificador de chip, un lugar para los datos por unidad y una forma de cerrar el puerto de depuración. Difieren en lo que es reversible. Si te equivocas en esto, el costo es una charola de piezas que no puedes recuperar.

Qué significa realmente «único» en cada chip

Cada familia sale de fábrica con un identificador, y el primer error es suponer que es el mismo tipo de cosa en todas.

STM32 expone un ID de dispositivo único de 96 bits en la memoria de sistema de solo lectura. ST afirma que es único para cada STM32 fabricado, y sus campos son coordenadas de la oblea, número de oblea y número de lote, no un valor aleatorio (ST: cómo obtener y usar el UID de 96 bits del STM32). Eso tiene dos consecuencias. Es un buen número de serie, y ST lo dice así. Es un mal secreto, porque las unidades del mismo carrete tienen IDs cercanos entre sí, y el valor puede ser leído por cualquier cosa que pueda ejecutar código en la pieza. El mismo artículo señala que la garantía aplica solo a las familias en las que ST prueba el UID en producción, así que revisa el manual de referencia de la pieza exacta antes de construir un esquema de seriales sobre él.

nRF52 tiene un DEVICEID de 64 bits y un DEVICEADDR de 48 bits en los registros de información de fábrica, ambos escritos por Nordic y no borrables. La dirección es la que el radio usa como dirección de dispositivo Bluetooth predeterminada. Los ingenieros de soporte de Nordic han dicho a los desarrolladores en DevZone que un valor garantizado como único en todo tu producto requiere tu propia numeración en el flujo de producción, ya que el ID de fábrica se genera en lugar de asignarse en secuencia. Toma eso como una guía de foro, y toma DEVICEID como un identificador que puedes leer, no como un serial que puedes imprimir en la etiqueta.

ESP32 guarda una dirección MAC de fábrica en el bloque 0 de eFuse y reserva parte del bloque 3 para una MAC personalizada o datos de usuario (administrador de eFuse de ESP-IDF). La MAC de fábrica es suficientemente única para una red Wi-Fi pero, de nuevo, no es un secreto.

El patrón es el mismo en las tres: el ID del chip identifica el die. El serial de tu producto identifica la unidad, y son cosas distintas. Una placa retrabajada con un MCU nuevo conserva su serial y recibe un ID de chip nuevo. Una impresora de etiquetas necesita un número que una persona pueda leer y que soporte técnico pueda consultar. Por eso el serial es algo que tú asignas y escribes, y el ID del chip es algo que registras junto a él en la bitácora de fabricación.

Dónde viven los datos por unidad

Una vez que aceptas que vas a escribir datos por unidad, la pregunta es dónde.

En STM32 las opciones prácticas son una página de flash reservada que la aplicación nunca borra, o los campos de datos de usuario de los option bytes en las familias que los tienen. Una página dedicada al final del flash es la más simple de razonar: el linker la excluye, el bootloader nunca la toca y el programador la escribe después de la imagen.

En nRF52 el UICR tiene registros CUSTOMER pensados exactamente para esto, y un bootloader como MCUboot o el bootloader DFU de Nordic no los borrará durante una actualización. La trampa en la que caen muchos en DevZone es el orden: un borrado completo del chip también borra el UICR, así que el serial debe escribirse después del borrado y después de cualquier archivo hex que también contenga contenido de UICR, o la segunda escritura borra en silencio la primera. Escribe el serial al final y luego léelo de vuelta.

En ESP32 el mecanismo previsto es una partición NVS de fábrica, y Espressif ofrece una utilidad de fabricación en masa que toma un CSV de configuración más una fila por dispositivo y genera una imagen de partición por unidad, opcionalmente cifrada con llaves por dispositivo (utilidad de fabricación en masa de ESP-IDF). La utilidad solo construye las imágenes. Grabarlas es un paso aparte con esptool o con el software de tu propio fixture, lo que significa que tu línea necesita una forma de elegir la imagen correcta para la placa que está en el fixture. Un código de barras en el panel o un serial leído del chip sirven ambos. Un montón de binarios nombrados por número de fila no sirve.

Los datos de calibración, si el producto los tiene, van en el mismo lugar que el serial y bajo la misma regla: los escribe el fixture, nunca la aplicación, y se leen de vuelta antes de que la placa salga.

Llaves y puerto de depuración: conoce lo que no puedes deshacer

Aquí es donde las familias divergen de forma marcada, y donde un paso equivocado es permanente.

Familia	Mecanismo	¿Reversible?
STM32	Protección de lectura nivel 1	Sí, regresar al nivel 0 borra todo el flash
STM32	Protección de lectura nivel 2	No, y el bootloader de sistema queda deshabilitado
nRF52	Protección del puerto de acceso	Sí, mediante ERASEALL, que borra el flash y el UICR
ESP32	Bits de eFuse (cifrado de flash, secure boot)	No, un bit quemado nunca se borra

En STM32, el nivel 1 bloquea la lectura del flash por el puerto de depuración y se puede deshacer, a costa de un borrado total; el procedimiento de ST indica que el borrado puede tardar un poco y no debe interrumpirse con un reset. El nivel 2 bloquea los option bytes de forma permanente y deshabilita el bootloader de sistema integrado, por lo que ST aconseja aplicarlo solo en la producción final, y únicamente si el producto tiene su propia ruta de actualización en la aplicación — el tipo de ruta que planea nuestra nota sobre diseñar actualizaciones de firmware con recuperación y reversión (ST: cambiar la protección de lectura en STM32F4). El mismo artículo advierte que un ST-LINK conectado, que se conecta al encender, puede interferir al entrar y salir de la protección. En un fixture, eso significa secuenciar la sonda de depuración deliberadamente, no dejarla conectada y esperar lo mejor.

En nRF52, las revisiones nuevas de silicio cambiaron las reglas. Las piezas anteriores dejaban el puerto de depuración abierto a menos que el firmware o el programador escribieran el registro de protección. Las piezas revisadas de Nordic quedan protegidas por defecto después de un borrado, y el propio firmware tiene que optar por dejar la depuración abierta (blog de Nordic sobre el APPROTECT mejorado). La trampa práctica es una compilación hecha con un SDK anterior que nunca escribe el registro: la placa sale del fixture bloqueada, y desbloquearla requiere un borrado completo. Confirma las versiones de SDK y MDK que usa la compilación contra la revisión del silicio que viene en el carrete, y agrega una lectura del «estado del puerto de depuración» a los criterios de aprobación del fixture.

En ESP32, la protección son eFuses, y cada quemado es en un solo sentido. El cifrado de flash tiene un modo de desarrollo que deja el contador de cifrado sin protección para que puedas volver a desactivarlo, y un modo de release que lo protege contra escritura. La documentación de Espressif indica que el cifrado en modo de desarrollo solo se puede desactivar un número limitado de veces por chip, y que no se debe interrumpir la alimentación durante el primer arranque con cifrado o el contenido del flash se corrompe (cifrado de flash de ESP-IDF). Secure boot v2 quema en eFuse un digest de tu llave pública, después de lo cual toda imagen futura debe estar firmada con la llave correspondiente, y Espressif recomienda generar las llaves de producción con una herramienta estándar y no con el script de conveniencia. Si pierdes esa llave, el producto nunca podrá actualizarse de nuevo. El fixture debe habilitar el modo release como su último acto, después de que todas las lecturas de verificación hayan pasado, y la alimentación del fixture debe ser lo último que alguien toque durante ese arranque.

Sobre el material de llaves en sí, la regla que se sostiene en las tres familias es: ningún secreto compartido entre unidades. Espressif dice que el cifrado de flash es tan fuerte como la llave y advierte explícitamente contra reutilizar una llave pregenerada en varios dispositivos. Las llaves por unidad dan más trabajo a la línea, y por eso pertenecen al diseño del fixture y al pipeline de CSV, no al historial de shell de alguien.

Planear el paso de programación

Un paso de aprovisionamiento que funciona en el banco y falla en la línea normalmente falla en la secuencia o en la evidencia — el mismo fixture que presiona los pogo pins sobre los puntos de prueba tiene que ser dueño de esta secuencia. Las verificaciones que construye un ingeniero cuidadoso:

• Borrar, programar, aprovisionar, proteger, en ese orden. Todo lo que se escribe antes de un borrado se pierde. Todo lo que se protege antes de una lectura de verificación no se puede inspeccionar.
• Lee de vuelta todo. Serial, calibración, digest de las llaves, estado de protección. Regístralo junto al ID del chip y la posición en el panel. Esta bitácora es lo que vas a consultar cuando regrese una unidad.
• Prueba la ruta de recuperación primero en una placa de desecho. Regresa un STM32 desde el nivel 1. Haz ERASEALL a un nRF52 y vuelve a aprovisionarlo. Confirma que un ESP32 en modo de desarrollo todavía se puede volver a grabar. Hazlo antes del primer lote real, para que la primera vez que necesites la ruta no sea en la unidad de un cliente.
• Mantén la depuración abierta en las compilaciones de desarrollo y cerrada en las de release, por configuración y no a mano. Una bandera de compilación visible en la cadena de versión es más fácil de auditar que una lista de verificación.
• Decide qué debe revelar una placa devuelta del campo. Si soporte necesita leer una bitácora por el puerto de depuración, el nivel 2 o los eFuses en modo release ya lo habrán hecho imposible. Elige el nivel de protección para toda la vida del producto, no solo para el día del envío.

El costo en tiempo es uno o dos días de software de fixture y una secuencia escrita. El riesgo de omitirlo es un lote que queda desprotegido o irrecuperable, y te enteras de cuál después del horno de reflujo.

Diseñamos la secuencia de aprovisionamiento junto con el fixture de pruebas y el firmware, de modo que el serial, las llaves y el bloqueo de depuración se escriben y verifican en una sola pasada en el mismo fixture que revisa la placa. Envíanos el MCU objetivo, tu estrategia de actualización y lo que soporte necesita poder leer más adelante, y te proponemos la secuencia y su ruta de recuperación.