Escribiendo Flash en STM32

3

Estoy implementando una EEPROM emulada en una memoria flash en un microprocesador STM32, principalmente basada en la Nota de Aplicación por ST (AN2594 - Emulación EEPROM en microcontroladores STM32F10x).

Los aspectos básicos que se describen allí y en la Hoja de datos respectiva y el Manual de programación (PM0075) son bastante claros. Sin embargo, no estoy seguro de las implicaciones del apagado / reinicio del sistema en la programación flash y las operaciones de borrado de páginas. AppNote también considera este caso, pero no aclara qué sucede exactamente cuando se interrumpen las operaciones de programación (escritura):

  1. ¿La dirección tiene un valor arbitrario (aleatorio)? O
  2. ¿Son solo parte de los bits escritos? O
  3. ¿Tiene el valor de borrado predeterminado 0xFF?

Gracias por las sugerencias o los punteros a la documentación relevante.

    
pregunta Arne

2 respuestas

2

La respuesta corta es que el hardware es inherentemente no confiable. En teoría, algo siempre puede ir mal, lo que interrumpe el proceso de escritura o hace que se escriba el bit incorrecto.

La respuesta larga es que los circuitos Flash generalmente están diseñados para ofrecer la máxima confiabilidad. Una pérdida repentina de energía en la escritura probablemente no causará daños porque el circuito del controlador puede tener suficiente capacitancia o la capacidad de operar en una condición de bajo voltaje el tiempo suficiente para terminar de drenar la carga según sea necesario. Una pérdida de energía en el borrado puede ser más complicada, ya que la bomba de carga de alto voltaje necesita completar su trabajo. Realmente necesitas consultar al fabricante. La solución es probablemente solo un capacitor de suministro de energía lo suficientemente grande.

Para un reinicio "suave" del sistema sin interrupción de la alimentación, sería bastante sorprendente que el hardware no siempre borrara por completo los bytes en los que estaba trabajando inmediatamente. Por lo general, los bytes se borran en un orden predefinido, por lo que puede usar el primero o el último para indicar si una página está llena o vacía.

¿Está tratando de mantener la integridad de los datos con alguna entidad externa (por ejemplo, si el widget está activo, entonces se escriben sus datos), o solo la autoconsistencia de los datos en sí? En este último caso, más razonable, debería concentrarse en marcar la finalización exitosa de cada operación de escritura y borrado dentro de la corriente de datos de Flash, para que las operaciones incompletas se vuelvan a intentar / ignorar en el reinicio sin importar la causa del error.

    
respondido por el Potatoswatter
0

En muchos dispositivos flash, borrar una página / bloque / sector / lo que sea necesario requerirá la programación interna de todos los bits a cero () y luego realizar un ciclo de borrado en todos los bits simultáneamente. En ocasiones, puede ser necesario repetir este proceso ( *). Si es necesario, dicha acción se realizaría automáticamente dentro del chip; La única consecuencia visible sería que un ciclo de borrado tomaría un tiempo inusualmente largo.

(*) STM parece usar lo contrario de la convención normal; los bits borrados en sus micros leen "0", mientras que los bits programados leen "1".

(**) He escrito software para un controlador que tenía que realizar todos los pasos "manualmente"; si algunos bits estuvieran "menos programados" que otros y terminaran de borrar primero, podrían evitar que los otros bits se borren correctamente, pero la reprogramación y el borrado de los bits supuestamente solucionaría el problema. No sé hasta qué punto los dispositivos flash más recientes tratan los mismos problemas.

Debido a que borrar un bloque primero requiere programarlo a todos los ceros (o, para ST, unos), no se debe esperar ningún comportamiento particular de un bloque parcialmente borrado a menos que o hasta que haya realizado otro ciclo de borrado en él, y este último ciclo se ha ejecutado hasta la finalización. Incluso si la página parece estar en blanco, no se debe confiar en ella. . Es posible que los bits que están parcialmente programados se lean en blanco pero a veces se lean como están programados. Escribir en una página aparentemente en blanco puede causar la pérdida de datos si los bits que aparecían en blanco, y se suponía que estaban en blanco, comenzaran a leerse como si hubieran sido programados.

Para evitar este problema, defina su formato de datos en memoria de modo que cada vez que se borre una página, se pueda discernir por el contenido de otras páginas, sin tener en cuenta el contenido de la página. página siendo borrada. Esto generalmente puede ser declarar que una página debe considerarse parcialmente borrada si otras dos páginas están de acuerdo con ese hecho, y organizar las cosas de modo que cuando se borra una página, dos páginas la digitarán, y ninguna página digite ninguna otra que pueda También se digite por la página que se está borrando; Una vez que se completa el borrado, al menos una de las páginas en las que se realizó la digitación debe programarse para que no lo haga. Luego, en el inicio, uno podrá identificar que existe una página parcialmente borrada, independientemente del contenido aparente de esa página, y repetir el comando de borrado para garantizar un borrado limpio.

    
respondido por el supercat

Lea otras preguntas en las etiquetas