Cuando tu microcontrolador llega a fin de vida

Un aviso de fin de vida del microcontrolador alrededor del cual construiste tu producto nunca llega en un momento conveniente. Por lo general aparece como un correo de una línea de un distribuidor, una bandera de estado que cambia en una búsqueda paramétrica, o un plazo de entrega que se desliza en silencio de ocho semanas a cincuenta y dos. Para cuando alguien lo nota, el reloj ya empezó a correr.

Qué inicia un aviso de EOL o NRND

“Fin de vida” y “no recomendado para nuevos diseños” son señales distintas, y conviene saber ante cuál estás. NRND significa que el fabricante seguirá produciendo la parte para los clientes existentes pero no quiere que la incluyas en nada nuevo: es una alerta temprana, no una fecha límite. Un aviso de EOL es la fecha límite: viene con una ventana de última compra (LTB), normalmente de unos meses, después de la cual la parte simplemente deja de fabricarse. El inventario de los distribuidores sobrevive a esa fecha por un tiempo, a veces años en una parte popular, pero inventario no es lo mismo que suministro: el día que se cierra una línea de fab, la cantidad de unidades en el mundo deja de crecer.

El error que más vemos es tratar cualquiera de los dos avisos como un problema de firmware o de compras en lugar de un problema de calendario. En cuanto llega un aviso, hay un número de unidades que todavía se necesitan para cubrir el tiempo hasta que salga un rediseño, y ese número determina si estás comprando tiempo con una orden LTB o si empiezas de inmediato una nueva versión de la placa. Las dos cosas requieren trabajo para hacerse bien, y las dos toman más tiempo del que parece desde afuera.

Las cuatro formas de responder

Última compra. Ordena de una sola vez suficiente cantidad de la parte para cubrir la producción hasta el rediseño o, en un producto que de todos modos está cerca del final de su vida, hasta el final de su corrida restante. Es la opción más barata a corto plazo y la única que no requiere nada de ingeniería. La contrapartida es el capital inmovilizado en inventario, el almacenamiento y el manejo de partes que pueden pasar años guardadas, y el riesgo de equivocarse con la cantidad en cualquiera de las dos direcciones. Compra tiempo; no resuelve el problema de fondo.

Alternativa drop-in. Algunos fabricantes publican un sucesor compatible en pines y en código de una parte descontinuada, justamente para evitar este problema; piensa en las líneas STM32 más nuevas que se mantuvieron compatibles en pines con un footprint anterior, o en un PIC de Microchip reemplazado por una parte de la misma familia con el mismo pinout y el mismo conjunto de periféricos. Cuando existe, es el mejor resultado: sin cambio de layout, con un cambio mínimo de firmware y un ciclo de calificación corto. Es lo bastante raro como para que no debas suponer que existe hasta haberlo verificado.

Miembro de la familia compatible en pines. Un paso por debajo de un verdadero drop-in: una parte de la misma familia, el mismo encapsulado, el mismo pinout, pero con un conjunto de periféricos distinto, más o menos flash, o una revisión de silicio diferente. La placa no necesita una nueva versión, pero el firmware sí necesita una revisión de fondo: los mapas de registros, los vectores de interrupción y el comportamiento de los periféricos pueden diferir incluso dentro de una misma familia.

Rediseño. Cuando nada en la oferta del fabricante original encaja (la familia misma llegó a EOL, el encapsulado cambió, o el reemplazo no tiene los periféricos que el producto necesita), la respuesta es un microcontrolador nuevo, a veces de un fabricante completamente distinto. Es la opción que más trabajo y más riesgo implica, pero también la que pone el producto en una parte con un horizonte más largo, en lugar de comprar unos años más con una parte que ya fue descontinuada una vez.

Cuál de estas aplica no siempre es obvio solo con la hoja de datos; por lo general hace falta una llamada al fabricante o a un FAE del distribuidor para saber qué se sigue fabricando realmente y qué aparece como “activo” por pura inercia.

Cómo calificar una alternativa como se debe

Sea cual sea la opción que aplique, calificar el reemplazo es donde los proyectos pierden más tiempo por sorpresas. Una calificación adecuada cubre:

Revisión	Qué detecta
Comparación de hojas de datos, línea por línea	Características eléctricas, tiempos, diferencias de pinout
Hoja de errata	Bugs de silicio que cambian cómo hay que usar un periférico
Encapsulado y footprint	Si la placa necesita una nueva versión o no
Mapa de periféricos	Qué timers, canales de ADC y bloques de comunicación cambiaron de pines o desaparecieron
Cadena de suministro, más de un distribuidor	Si la “alternativa” ya tiene poco inventario o es NRND
Estado del ciclo de vida de la alternativa	Si estás por repetir este ejercicio en dos años

Esa última línea importa más de lo que parece. Hemos visto alternativas elegidas bajo presión de tiempo que a su vez quedaron marcadas como NRND en menos de dieciocho meses, porque nadie revisó el estado del ciclo de vida de la parte que se calificaba como solución; es la misma trampa que describimos al hablar de conseguir una segunda fuente para una sola parte de flash.

Qué suele romperse al portar firmware a otro fabricante

Mover firmware entre familias de microcontroladores, por ejemplo de un proyecto STM32 a un Nordic nRF52, o de un PIC de Microchip a un TI MSP430, es donde está el verdadero trabajo de ingeniería, y donde un calendario suele atrasarse si no se presupuestó con honestidad.

El árbol de reloj y la configuración del PLL casi nunca se pueden copiar y pegar. Cada fabricante tiene su propia manera de derivar los relojes del núcleo, de los periféricos y del USB a partir de un cristal o de un oscilador interno, y equivocarse no siempre falla de forma evidente: a veces la velocidad de un UART queda desviada medio por ciento y nada parece estar mal hasta que algo falla. Los nombres de los periféricos y el DMA son la siguiente trampa: un “timer” en la parte de un fabricante no necesariamente tiene las mismas capacidades que un “timer” en la de otro, y la asignación de canales de DMA, los disparos y los modelos de buffering difieren lo suficiente como para que el código construido alrededor del controlador DMA de un fabricante normalmente haya que repensarlo, no traducirlo. El bootloader y la distribución de la flash también necesitan una mirada nueva: tamaños de página de flash distintos, regiones reservadas distintas y un protocolo de programación en sistema distinto afectan cómo se entregan las actualizaciones en campo. Las diferencias de HAL y SDK son las más visibles pero no las más peligrosas: el HAL de STM32, el SDK de Nordic, MPLAB Harmony de Microchip y driverlib de TI modelan el mismo hardware de maneras distintas, y un port directo función por función tiende a arrastrar los supuestos del fabricante anterior de maneras que no se notan hasta las pruebas de integración. Las herramientas de depuración también cambian: un programador distinto, un IDE distinto y, a veces, un conjunto de instrucciones completamente distinto si el rediseño abandona ARM Cortex-M, lo cual es un costo real aunque nadie lo ponga en el plan del proyecto.

Las consecuencias mecánicas

Una parte que no es compatible en pines arrastra consigo el diseño mecánico. Un footprint distinto significa que el layout se mueve, lo que puede mover las zonas de exclusión, lo que puede invadir espacio alrededor del cual se diseñó el gabinete. Cuando es posible, mantenemos fijos el conector y el gabinete y dejamos que el layout interno absorba el cambio; así el herramental, el cableado y las partes de servicio en campo del producto no se ven afectados aunque la placa de su interior sea nueva. Cuando también hay que cambiar el gabinete, es un segundo ciclo de diseño encima del primero, y conviene saberlo desde el principio en lugar de descubrirlo durante la revisión de ajuste.

Cómo probar la nueva versión de la placa

Una nueva versión de la placa, por pequeña que parezca en papel, se prueba como una placa nueva. Eso significa una lista de verificación de bring-up antes de que corra cualquier otra cosa (rieles de alimentación dentro de tolerancia, reloj presente y correcto, interfaz de programación y depuración respondiendo), seguida de una comparación lado a lado contra una unidad conocida y buena del diseño original, verificando que el comportamiento coincida en cada interfaz que expone el producto, no solo en las que se esperaba que cambiaran. De ahí pasa por la misma prueba de producción que corre la placa original, porque un fixture construido para el pinout y los tiempos de la parte anterior normalmente necesita sus propias actualizaciones, y esa actualización es fácil de olvidar hasta que la primera unidad falla una prueba que nunca se reescribió. Solo después de eso se trata como un diseño liberado.

Qué enviarnos

Si una parte alrededor de la cual construiste acaba de llegar a EOL o NRND, la forma más rápida de obtener una respuesta directa es enviar: el aviso mismo, el esquemático y la BOM actuales, las cantidades y el calendario con los que estás trabajando, y cualquier código fuente de firmware que exista. Con eso podemos decirte en uno o dos días cuál de los cuatro caminos anteriores aplica realmente a tu placa y qué implicaría.