Segunda fuente para la flash SPI de una placa

Llega una pregunta de compras con dos números de parte: la flash que ya está en la placa y un reemplazo propuesto. Ambas tienen la misma capacidad anunciada y un encapsulado parecido; es la misma trampa que tiende el “mismo valor, mismo tamaño” con un capacitor cerámico sustituto. La respuesta tentadora es comprar unas cuantas, programar una y aceptar el sustituto si la aplicación arranca.

Eso es una evidencia inicial útil, pero deja sin probar buena parte del producto. La estación de programación, el código de arranque, el actualizador de firmware y la aplicación pueden acceder cada uno a la flash de manera distinta. Un reemplazo debe funcionar a través de toda esa cadena, incluida la recuperación después de una actualización interrumpida.

Esta nota describe un plan de revisión para conseguir una segunda fuente de flash SPI NOR. No es una lista de partes intercambiables. La decisión depende de los códigos de pedido exactos, del diseño de la placa y de las versiones de software del producto.

Empieza por la placa y el encapsulado exacto

Registra el número de parte existente con todos sus sufijos, el número de parte propuesto y la revisión de la placa. Compara sus requisitos de alimentación y de E/S, condiciones de operación, asignaciones de pines, planos del encapsulado y patrones de pads recomendados antes de montar muestras. Compartir el nombre de la familia o el número de pines no establece compatibilidad.

Revisa qué hace cada señal durante el arranque y el reset, además de las transferencias normales. Los pines que llevan líneas de datos adicionales en un modo pueden tener funciones de control en otro. Las resistencias de pull de la placa, el estado de arranque del MCU y la secuencia de reset son parte de la comparación.

No supongas que el footprint de un cuerpo más ancho acepta uno más angosto. Compara la geometría real de las terminales y el traslape con los pads para cada candidato. Si un encapsulado incluye un pad expuesto, sigue los requisitos de conexión de ese candidato. Cualquier footprint compartido que se proponga necesita su propia revisión de ensamblaje.

El mismo cuidado aplica a los límites eléctricos. La frecuencia de reloj existente y el layout de la placa son datos de entrada de la calificación, no una prueba de que un sustituto pueda operar con los mismos ajustes. Registra los límites relevantes de la documentación de cada candidato para que la decisión pueda revisarse después.

Identifica los supuestos del software

Muchos drivers admiten varias familias de flash, pero un driver que funciona no necesariamente está configurado para todos los candidatos. Incluye en el paquete de revisión el MCU, el controlador, la versión del framework, el bootloader, la configuración del driver de flash y la herramienta de programación de producción.

La configuración del modo quad es un ejemplo de un supuesto que depende del fabricante. El binding de SPI NOR de Zephyr documenta varios métodos para habilitar quad, con distintas ubicaciones de registros y un caso en el que no se necesita ningún bit de habilitación quad. También expone ajustes relacionados con el direccionamiento y con los parámetros de la flash. Esa es una razón para inspeccionar la ruta del driver seleccionado en lugar de copiar la secuencia de escritura de registros de la parte anterior.

Compara los comandos y ajustes que el producto realmente usa: modos de lectura, actualizaciones del registro de estado, protección, operaciones de borrado, apagado y recuperación. Un modo que la aplicación nunca ejercita puede quedar fuera del alcance de calificación del producto, pero un modo que usa su actualizador o su programador de fábrica no.

Los cambios de capacidad requieren atención especial a los límites de direccionamiento y de particiones. Confirma que cada etapa del software puede alcanzar las regiones previstas y que el formato de imagen, la configuración del linker y la distribución de la actualización concuerdan. Que se reporte un tamaño de dispositivo mayor no extiende automáticamente esos otros límites.

Usa parámetros descubribles donde se admitan

Serial Flash Discoverable Parameters, o SFDP, entrega información del dispositivo en tablas estandarizadas. La documentación de SPI NOR de Linux explica cómo su driver puede usar esas tablas para un sondeo genérico. También describe excepciones: las tablas mal formadas o las funciones que las tablas no cubren pueden requerir soporte explícito y correcciones.

La conclusión práctica es limitada: un descubrimiento exitoso reduce algunos supuestos fijos en el código, pero no certifica el producto. Conserva la lectura y la identificación del driver en el registro de calificación. Si el firmware usa una configuración fija en lugar de descubrimiento en tiempo de ejecución, documenta cómo se derivó esa configuración para cada candidato aprobado.

No supongas que el código de arranque tiene las mismas capacidades que el driver de la aplicación. Establece qué software accede primero a la flash externa en este producto y cómo selecciona un modo de lectura. Un cambio de firmware que corre solo después de cargar el código externo no puede reparar una falla de arranque anterior.

Como otro ejemplo concreto, la documentación de la API SPI Flash de ESP-IDF lista las familias de flash compatibles con el modo quad y distingue las funciones opcionales. Exige verificar el soporte tanto en el destino como en los dispositivos de flash para esas funciones. Usa la documentación del destino y de la versión de framework reales; una afirmación sobre una configuración de ESP32 no es una regla universal para otros controladores.

Califica la ruta completa del producto

Escribe el plan de aceptación antes de aceptar un lote de reemplazo. Lo siguiente es una lista de verificación de ingeniería para adaptar a los requisitos del producto, no un estándar de calificación de proveedores.

1. Programa un candidato nuevo con el proceso de producción. Incluye borrado, programación, verificación y cualquier aprovisionamiento que use el producto que se envía. Registra las versiones de la herramienta y del firmware.
2. Ejercita las rutas de arranque y de reset. Revisa arranques en frío, resets del MCU y las rutas de recuperación relevantes para el diseño. Verifica que la identificación y la configuración de la flash coincidan con lo esperado.
3. Prueba las cargas reales de lectura y escritura. Incluye las regiones, los modos y las condiciones de operación que requiere el producto. Revisa la integridad de los datos después del borrado y la programación, no solo si la aplicación llega a su pantalla principal.
4. Corre el proceso de actualización en campo. Prueba una actualización exitosa, una imagen rechazada donde aplique y la recuperación de actualizaciones interrumpidas a propósito en hardware de calificación. Define de antemano el estado recuperable esperado.
5. Revisa el comportamiento de tiempos y de consumo. Usa los requisitos ambientales y eléctricos del producto para fijar las condiciones de prueba. No inventes un número universal de muestras o de ciclos.
6. Registra la decisión de liberación. Vincula los códigos de pedido aprobados con la revisión de la placa, la configuración del software y la evidencia. Enumera explícitamente las restricciones sin resolver.

Una interrupción de la alimentación y un comando de suspensión de borrado son eventos distintos. Prueba cada uno solo donde sea relevante, con resultados esperados separados. Que un dispositivo admita suspensión no hace por sí mismo que una escritura o una actualización interrumpida sea recuperable.

Convierte el resultado en una instrucción de compra

Un experimento de banco aprobado debe convertirse en una decisión explícita de alternativa aprobada. Pon los códigos de pedido exactos que se calificaron en la BOM controlada o en el registro de partes aprobadas. Especifica cualquier versión de firmware o cambio de ensamblaje que lo acompañe. De lo contrario, compras puede elegir un sufijo relacionado que nunca se evaluó, o una construcción posterior puede reutilizar la configuración anterior.

Si un candidato necesita un cambio de placa, compara ese esfuerzo de ingeniería con la vida restante del producto y con sus necesidades de suministro. Si solo necesita un cambio de driver, las implicaciones de la actualización y de la base instalada también pertenecen a la decisión. El reemplazo menos disruptivo es el que respalda la evidencia completa, no necesariamente el que se ve más parecido en un catálogo.

Para una revisión de rediseño por suministro, envía el esquemático, el layout o los datos del encapsulado, los códigos de pedido actual y propuesto, el MCU, las versiones de firmware y el proceso de programación de producción. Con esos datos es posible separar a un candidato plausible de un sustituto aprobado y definir el trabajo necesario entre ambos.