6 votos

¿Un chip de memoria flash SPI tendrá los mismos problemas con las operaciones de escritura no atómico como un dsPIC ' s EEPROM interno?

Hace un tiempo tuve algunos problemas intermitentes con la memoria EEPROM interna de un dsPIC. Cada tan a menudo, algunos de valor de la EEPROM se encontraría ceros en el encendido. Me guié por el problema a cuando el chip perdió el poder después de borrar el paso de los ciclos de escritura, pero antes de que la escritura se había completado. Era todo acerca de la oportunidad de la energía hacia abajo en relación con el firmware de la ejecución, lo que fue (en funcionamiento normal) de forma aleatoria. Lo resuelto por la adición de una sección de memoria a mi EEPROM, para asegurarse de que la escritura incompleta-ciclo podría ser completado en la restauración del poder. Tuve que dar la EEPROM escribe en una operación atómica.

Ahora estoy usando una diferente dsPIC sin memoria EEPROM interna, y estoy tratando de utilizar un flash externo chip de memoria para almacenar datos persistentes. Me pregunto si debo tienen preocupaciones similares. Debo estar preocupado de que mi flash externo chip se apaga mediados de escribir y perder los datos, y escribir una corrección para esta en mi firmware como yo lo hice de memoria EEPROM interna? ¿O es que el propio chip de garantía atómica operaciones de escritura?

Para más detalles, mi búfer técnica define un área de la persistencia de la memoria que consta de tres campos: dirección de escribir, la escritura de datos, y LISTO bandera. Una "escritura" se compone de cuatro pasos: escribir en el búfer, prepara a la bandera, escribir a partir de búfer, claro LISTO bandera. En la puesta en marcha, compruebe el LISTO de la bandera. Si se establece, ejecutar cualquier cosa en el búfer. Esto funcionó bien en la EEPROM, pero no estoy seguro de si va a funcionar bien en flash.

5voto

GSerg Puntos 33571

Nunca he oído hablar de un chip de memoria flash (o procesador con flash interna) que tiene suficiente almacenamiento de energía internamente para completar una escritura (o borrar) ciclo si de alimentación externa debe ser eliminado. En otras palabras, si usted no tiene control sobre cuando su sistema se apaga, siempre necesidad de crear un protocolo que puede detectar y tratar con cualquier persona flash operación de actualización que podría haber sido interrumpido.

Una forma de evitar esto es para proporcionar la energía necesaria de almacenamiento (por ejemplo, un condensador electrolítico) en su consejo de administración, de tal manera que usted puede detectar un fallo de alimentación externa, sin embargo, todavía completa de escritura/borrado de operación que pueden ya han comenzado.

EDIT: Su buffer de escritura en concepto puede ser utilizado con el flash externo, pero no necesita ser modificado para tomar en cuenta la mayor borrar granularidad. De acuerdo a la hoja de datos, el mínimo borrar el tamaño es un "sector" (4K bytes).

Usted necesitará reservar tres sectores para su buffer de escritura. Uno de estos se mantienen, la lista de la bandera (llamamos a esto el WB_R wector). La segunda contendrá la dirección del sector del sector que se actualiza (llamamos a esto el WB_A sector). El tercero, mantener los datos actualizados para el sector (llamamos a esto el WB_D sector).

Para actualizar cualquier byte (o de un grupo de bytes en un solo sector), siga los siguientes pasos. Suponemos que WB_R ya está borrado.

  1. Borrar WB_A.
  2. Busque el flash sector que contiene el byte desea cambiar (llamar a este el DESTINO del sector).
  3. Escribir la dirección del sector de DEST a WB_A.
  4. Borrar WB_D.
  5. Copiar el contenido de DEST a WB_D, pero cuando llegas a el byte(s) que vas a cambiar, escriba el valor nuevo(s) a WB_D en lugar del valor anterior(s).
  6. Establecer el LISTO de la bandera en WB_R. Tenga en cuenta que esto significa que usted cambia a su no-borrado del estado. Desde el borrado del estado es 0xFF, esto significa que usted escribe 0x00.
  7. Borrar DEST (obtención de la dirección del sector de WB_A).
  8. Copiar el contenido de WB_D a DEST.
  9. Borrar WB_R.

En el encendido, compruebe el LISTO de la bandera, y si se trata de un set (otra cosa que 0xFF — puede haber sido sólo parcialmente por escrito o parcialmente borrado), saltar directamente al paso 7.

Tenga en cuenta que con este algoritmo, cada uno de los buffer de escritura sectores se escriben y se borran al menos una vez para cada operación de escritura que hacer. Esto podría convertirse en un problema si usted hace un montón (más de 100.000) escribe sobre la vida útil del producto. Si ese es el caso, usted necesitará un más sofisticado de nivelación de desgaste algoritmo.

3voto

Van Gale Puntos 387

El búfer de escritura no es suficiente. Usted necesita tomar una hoja en el archivo de base de datos y sistema chicos aquí: usted necesita una estructura de datos en flash que se puede recuperar a un "buen" estado cuando un bloque está dañado.

Una manera habitual de hacer esto es a ping-pong entre dos bloques. Hacer que los últimos dos o cuatro bytes de los bloques de ser el "número de serie" del bloque, y el resto de datos en el resto del bloque. Cuando se escribe un nuevo bloque, incrementar el número de serie del bloque anterior por uno, omitiendo el borrado "0" el valor (que puede ser 0xff, dependiendo del tipo flash) y escribir el nuevo bloque con ese número de serie.

En el encendido, leer los dos bloques, y ver que uno tiene después del número de serie (teniendo en cuenta la envoltura de 0xffff->0 y haciendo caso omiso de la omitido borrar valores). El uso de ese bloque. Usted también puede querer agregar un CRC de los datos para verificar que no fue dañado en el medio (aunque si pones el serial al final, que "no debería" ser un problema).

Si usted tiene complejo de datos, se pueden ampliar esta en la forma en que una base de datos o sistema de archivos de la actualización de un árbol en el disco, o incluso implementar escribir el registro.

2voto

AitorTheRed Puntos 241

Esta es un área donde usted necesita para sentarse y cuidadosamente estrategias cosas. Algunos detalles de la hoja de datos son:

  1. Sector de 4 kb de borrar: \$400ms\$ peor de los casos
  2. 32k bloque borrado: \$800ms\$ peor de los casos
  3. Bloque de 64 kb de borrar: \$1000ms\$ peor de los casos
  4. página de escritura: \$3ms\$ peor de los casos
  5. el primer byte de escritura: \$40\mu s\$ peor de los casos
  6. siguiente byte a escribir: \$12\mu s\$ peor de los casos

Es probablemente una buena idea, si usted tiene control sobre este detalle, para organizar el poder local (a través de un condensador almacena carga) que se mantendrá a sí misma dentro de una "caída del margen" determinar mientras que el crítico escribe tomar su lugar. Esto no tiene que ser un completo segundo, si el uso inteligente del primer byte de escritura de temporización (no olvides incluir adicional de comunicación/configuración veces con eso.) Puede actualizar sólo uno o dos bytes en una página especial que significa que un bloque o sector de borrar se inicia, por ejemplo. Esto permite determinar, si la experiencia de un (brown-out) o reset, donde estuvo por última vez en así que usted podría terminar el proceso. Usted puede necesitar más de una "página especial". Pero, en cualquier caso, usted necesita a estudiar a fondo todos los casos!

1voto

Alex Andronov Puntos 178

Si se pierde la energía, mientras que un chip flash es borrar el bloque, robusto software debe asumir que los contenidos del bloque puede cambiar arbitrariamente en cualquier momento , a menos que o hasta que el bloque se vuelve a borrar y una eliminación ciclo se ejecuta hasta el final. Incluso si el bloque todavía parece mantener los datos antiguos, no hay garantía de que va a seguir haciéndolo para cualquier longitud de tiempo. Incluso si el bloque parece ser borrado, no hay ninguna garantía de que programar los bits no espontáneamente "aparecer". Yo he visto un par de procesadores con flash interno que incluye una capacidad de comprobar si los bits eran "de verdad" suprimidos o eran "completamente" programado, pero nunca he visto la funcionalidad expuesta por un flash externo del dispositivo.

Si uno desea ser capaz periódicamente almacén de datos en la flash, y asegurar que en caso de fallo de la alimentación de cada actualización se realizará correctamente completamente o no de todo, uno debe tener al menos tres bloques de flash, y definir un protocolo que cada vez que un bloque se borran, se puede determinar que se basaba únicamente en el contenido de los otros dos bloques. Hay una gran variedad de protocolos para la aplicación de esta; yo voy a sugerir una simple aquí, suponiendo que la cantidad de información que se almacena es un bloque completo menos un tamaño mínimo de los programable unidad, y tres bloques están disponibles, que llamaré X, Y, y Z.

Cada bloque tendrá un "control" de los bits dentro de lo que está reservado para el seguimiento de la validez/supresión de estado; voy a llamar a los bits de x, y y z. Durante la operación, el sistema mantendrá el invariante que el bloque que contiene los datos correctos tendrá su bit de control en blanco; el "anterior" (bloque X está precedido por Z) tendrá su bit de control programado. Los bits de control para el bloque restante (el "después de" el uno con datos válidos) será irrelevante. Si todos los bits de control están en blanco, nunca nada ha sido correctamente escrito; si todos los bits de control programado, algo que ha conseguido seriamente dañado.

Para la escritura de nuevos datos, borrar el bloque siguiente al de la que tiene los datos correctos, a continuación, almacenar nuevos datos en ese bloque. Finalmente, como último paso, el programa de control poco de lo que solía ser el bloque actual. Hasta que el bit de control está programado, nada la atención acerca de los contenidos del bloque que se acaba de programar. Una vez que el bit está programado, nada la atención acerca de los contenidos del bloque siguiente el nuevo bloque. Siempre que el sistema tiene suficiente energía disponible para asegurar que la programación de que un bit sea éxito o no de manera limpia, confiable de la operación está asegurada en todos los power-escenarios de pérdida.

Supongamos que x es programado, y es en blanco, y z es cualquier cosa. Debido a que los datos válidos bloque debe tener su propia bandera en blanco y el bloque anterior de la bandera debe ser programado, X no puede ser un válido bloque (bandera de x está programado), y Z no puede ser un válido bloque (porque la bandera y está programado). En consecuencia, Y es el único bloque que puede contener datos válidos. Bloque X tiene la versión anterior de los datos, y Z no puede ser invocada para celebrar nada. Cuando es necesario para almacenar los nuevos datos, el código debe comenzar por el borrado de Z (independientemente de si ya aparece en blanco), y la programación de todos los datos que debe contener. Si se pierde la energía en cualquier momento durante este proceso, el estado del sistema será el mismo que antes de que comenzaran (basado en los indicadores, el contenido de Z se presume que el significado, por lo que su contenido no afectar el estado del sistema en todos).

Sólo después de que todas las escrituras a la Z es completa y contiene datos válidos deben bandera y ser programado. Una vez que la bandera está escrito, Z será reconocible como el bloque que contiene datos válidos desde su propia bandera estará en blanco mientras que las anteriores bloques' de la bandera (y) es programado; el hecho de que y está ahora programado significa Y no es válida.

La próxima vez que es necesario para almacenar los nuevos datos, el bloque X debe ser borrados y los datos allí almacenados; finalización debe ser indicado por la programación de la bandera z. El tiempo después de eso, Y deben ser borrados y los datos allí almacenados, con la finalización indicada por la programación de la bandera de x. Es vital que intenta programa de indicadores de x, y y z, ya sea completado o no tienen ningún efecto, pero esas son las únicas operaciones que deben ser "garantizado atómica" en el nivel de hardware. Todos los demás se escribe en la memoria se hace a un bloque cuyo contenido nunca se miró(*) a menos que se ejecute hasta el final.

(*) El sistema por lo general no será capaz de evitar el acceso no válidos del bloque, pero el comportamiento del sistema se ve afectada por el valor leído.

Por CIERTO, si uno no confía en la capacidad de garantizar que la bandera escribe ejecutar hasta el final, existen varios enfoques redundante con la bandera de bits, lo que potencialmente podría ayudar un poco, pero la fiabilidad no será más seguro. Supongamos, por ejemplo, que el sistema pierde energía, mientras que poco y es parcialmente programado de tal manera que a veces se lee como programado, pero a veces como en blanco. Si en el primer encendido, y se lee como en blanco, la próxima actualización de borrar Z. Si durante ese borrado, el sistema pierde energía y en el siguiente power-up, y se lee como programado, el sistema de suponer que Z es el válido bloque. Y si había leído como programado dos veces, entonces Z habría sido válido bloque y el siguiente bloque de borrado habría sido X. Si había leído como blanco dos veces, entonces Z habría sido reconocido correctamente el segundo tiempo como el bloque no válido. A pesar de que uno podría tratar de protegerse contra estos peligros mediante la adición de redundante bandera de bits, tales enfoques no ayuda mucho. Uno puede diseñar de tal manera que sería "poco probable" para parcialmente programadas indicadores de comportarse en la problemática de la moda, pero que es fundamentalmente diferente de la garantía de que si la bandera escribe trabajo atómicamente, nada de lo que el chip podría informar de cualquier otra parte por escrito los datos podría causar problemas.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X