W25Q80: Pérdida de datos

El problema se resuelve de una manera interesante.

Según el proveedor, la versión anterior de la placa tiene una entrada analógica (algo así como CVBS) y una entrada de interruptor para cambiar la fuente de entrada de pantalla activa de HDMI o VGA a esa entrada analógica. Ahora, la versión actual de la placa no contiene tanto la entrada analógica como el interruptor. Así que los pines correspondientes del chip controlador se dejan abiertos. Pero el controlador tiene el software cargado para la versión anterior de la placa.

Dijo que debido a que el pin de entrada del interruptor se ha dejado abierto, podría haber captado ruido debido a su alta impedancia y haberlo traducido a una entrada de conmutación. Y dado que el software no está actualizado, el controlador intentó cambiar la fuente de entrada a CVBS que no se proporciona y, por lo tanto, no pudo iniciarse.

Me suena como una explicación lógica.

Por lo tanto, la declaración "el software se ha ido" parece no ser cierta. Esa fue una situación totalmente diferente.

De todos modos, el problema está resuelto.

Si está realmente seguro de que se debe culpar a flash (y no de firmware u otra cosa), le sugiero que intente usar el dispositivo con flash protegido contra escritura. Hay un pin para eso, por lo que sería una modificación mínima del hardware (puede ser un problema si el circuito usa, por ejemplo, Quad-SPI, porque entonces el pin WP no está disponible).

Dos cosas:

1. Usted dice que el dispositivo funciona 12 horas por día durante un mes, y supongo que estas 12 horas son horas continuas. Así que lo primero que viene a la mente es la temperatura. La versión comercial del dispositivo flash tiene una clasificación de 0 a 70 C, sin embargo, a mayor temperatura, mayor probabilidad de mal comportamiento. Verifique las condiciones y asegúrese de que haya suficiente enfriamiento alrededor e insider el dispositivo.

2. Puede suceder que el controlador maneje el chip flash con un comando de habilitación de escritura emitido cuando no debe hacerse. Si es el caso, si toca la línea SPI puede causar arbitrariamente un flash, vea el comando "borrado de sector" o uno similar, y de esta manera realice esta operación. Para confirmar o negar mi teoría, debe analizarse la interacción SPI y, cuando se produzcan daños, descargue los contenidos flash y compárelos con el original para averiguar si algún sector crítico se está llenando con FF (borrado). Tales situaciones me ocurrieron cuando manejaba el flash de configuración en serie usando FPGA, y es absolutamente necesario tener la escritura deshabilitada (no habilitada, por comando y eléctricamente cuando sea posible) para no tener errores como usted describe.