El rendimiento de la tarjeta MicroSD se deteriora tras un uso prolongado de sólo lectura

Question

Estoy utilizando un microcontrolador STM32L432 para leer datos de una tarjeta microSD a través de SPI. En mi aplicación, estoy reproduciendo un archivo de sonido con una duración de 10 s en bucle.

Descubrí que después de que la aplicación se ejecutaba durante aproximadamente 20 - 25 horas, el flujo de audio se interrumpe fuertemente por brechas notables que se producen varias veces por segundo. Esto se puede observar en el 10% de todas las tarjetas microSD que probé. Ocurre con SanDisk, Kingston y todas las demás marcas que he probado. Detener la aplicación y dejar que la tarjeta microSD descanse durante algunos días no resuelve el problema. Parece que la sección flash de las tarjetas microSD que almacena el archivo de sonido se ha deteriorado. Reformatear la tarjeta microSD lo arregla, probablemente porque el archivo de sonido se almacena en otra sección flash.

Una investigación más a fondo ha revelado que los huecos en el flujo de audio se producen porque la tarjeta microSD tarda demasiado en responder al comando CMD17. Cuando la tarjeta microSD es nueva, las respuestas nunca tardan más de 4 ms en nuestras pruebas. Sin embargo, después de un uso de 20 a 25 horas, el tiempo de respuesta aumenta hasta 95 ms en el 10% de las tarjetas microSD.

Estoy un poco confundido de este resultado porque no esperaba que el rendimiento de las tarjetas microSD se deteriorara si sólo se realizaban operaciones de lectura. ¿Tenéis alguna experiencia al respecto? ¿Disminuiría el tiempo de respuesta al utilizar SDIO en su lugar?

Answer 1

Hm, mi sospecha habitual sería que su acceso de lectura pasa por un sistema de archivos y que actualiza algo, por ejemplo un tiempo de acceso al archivo, en el sistema de archivos, pero no parece ser el caso aquí.

Lo siguiente que supongo: Estás experimentando Leer más La lectura de la misma celda una y otra vez carga las celdas de memoria vecinas ligeramente cada vez, o la consecuencia de que el controlador de la memoria flash lo evite:

Probablemente sepas que entre la interfaz de tu tarjeta SD y las cargas físicas aisladas de la puerta de tu flash NAND, hay múltiples capas de abstracción:

1. Hay una tabla de mayor fiabilidad que mapea las direcciones de bloque "externas" a las internas, de modo que para proporcionar nivelación del desgaste es decir, evitar escribir en un solo bloque hasta que falle
2. Hay (en muchos casos) cantidades abundantes de códigos de corrección de errores (ECC): La memoria flash es barata. No se pueden fabricar mil millones de MOSFET de tamaño nanométrico sin tener un par de ellos menos fiables. Además, en el caso de las memorias multinivel, hay más de un bit almacenado en el valor de la carga de la puerta, por lo que también hay un límite "suave" sobre qué significa qué. Tendrás que añadir un algoritmo que tome las cosas en bruto almacenadas en las celdas de la memoria flash, compruebe si parece correcto y, si no lo es, lo corrija. Ese es el trabajo de ECC, y normalmente, leer sólo las celdas "buenas" es mucho más rápido que corregir los datos "parcialmente erróneos".
3. Los tamaños de las palabras en la memoria no coinciden necesariamente con los tamaños de las palabras en el bus externo (SPI/MMC/xSD, lo que sea), así que a menudo hay alguna operación de "obtener más e ignorar todo lo que no se pidió" o "obtener múltiples y ensamblar lo que se pidió".

y, aquí:

4. Para evitar la carga de las celdas vecinas a través de la perturbación de la lectura, el controlador toma las celdas de lectura frecuente y las redistribuye después de un número umbral de lecturas. Esta redistribución lleva tiempo.

Si lees las mismas celdas con CMD17 (que seguramente será muy poco óptimo en términos de 3., ¿usar CMD18 tal vez?) suena mucho a que estás corrompiendo a sus vecinos (lo que lleva a un aumento del tiempo en 2.) o a que estás llevando a cabo un copioso re-mapeo de bloques (en 4.).

Estoy un poco sorprendido: la lectura de audio parece una operación de bajo rendimiento, en comparación con, por ejemplo, la lectura de las fotos de la cámara, pero si su patrón de acceso es muy ineficiente, por ejemplo, usted lee un byte utilizando CMD17; el controlador de la flash tiene que obtener un bloque completo de 2048 B¹, luego corregirlo, tirar todo el byte del resultado menos uno, devolver ese byte a la interfaz SPI, y entonces usted lee otro byte, que requiere que el controlador de la flash lea 2048 B, corrija. . y así sucesivamente, ¡podrías estar haciendo un múltiplo muy alto del acceso de lectura real que crees que estás haciendo! Eso es desafortunado, porque la lectura de audio es probablemente bastante secuencial.

Por lo tanto, mi recomendación es escribir una interfaz de tarjeta SD SPI más inteligente que obtenga bloques largos de datos y los almacene en caché en la RAM de la MCU. Este

• puede erradicar por completo los problemas de latencia aleatoria, ya que se puede empezar a obtener el siguiente bloque grande en cuanto el primero termine de obtenerse a través de SPI, de modo que siempre se disponga de una gran cantidad de búfer de lectura.
• aprovecha mejor el ancho de banda del bus
• permite que el controlador de la memoria flash sólo acceda realmente a las celdas de memoria sin procesar la cantidad necesaria de veces
• convierte una operación que lee una pequeña cantidad de datos a menudo en una operación que lee una gran cantidad de datos raramente, permitiendo que muchas cosas vuelvan a estar en reposo entre ellas, lo que puede ayudar a ahorrar batería

---

¹Número extraído de una suposición aleatoria, pero el orden de magnitud se ajustaría al tamaño de los códigos de bloque de corrección de errores que yo esperaría en las modernas y baratas memorias NAND.