Revisión de manipulación de memoria ESP8266

Si alguna vez ha dañado una memoria flash debido a un corte de energía, le alegrará saber que el ESP8266 SDK realiza una lectura / escritura muy segura y casi infalible para su memoria flash. El truco: también es un desperdicio. Para un solo bloque de memoria de datos almacenados, se ocupan tres bloques de memoria de la memoria flash física. [Peter Scargill] nos ilumina con una mejor solución.

Cuando el ESP8266 escribe datos en su memoria de bolsillo externa, por ejemplo, durante una actualización de OTA, no puede simplemente reemplazar el bloque que contiene el programa que se está ejecutando actualmente; necesita escribir esos datos en un segundo bloque. Una vez que se completa la operación de escritura, debe rastrear qué bloque contiene los datos actuales. Para ello, el ESP8266 SDK utiliza un tercer bloque en el que almacena el puntero al bloque actual. Sin embargo, aparte del puntero de bloque, este tercer bloque no almacena datos útiles.

Es una técnica intencionalmente derrochadora extremadamente útil para actualizaciones de firmware a prueba de balas, pero para mantener datos adicionales en la memoria flash, querría un método más eficiente. [Peter] logró lograr la misma integridad de datos utilizando solo dos bloques por bloque de datos almacenado. Su método agrega un contador de versión de 8 bytes a cada bloque: cuando se lee un bloque, las calculadoras de versión se comparan para recuperar los datos actuales; cuando se escriben datos, el contador de versiones le permite determinar qué bloque es el más antiguo y puede ser inscrito.

[Peter] inicialmente coloque el contador de versiones al final de un bloque, por lo que naturalmente se escribiría después de que el resto del bloque se haya escrito correctamente. Desafortunadamente, la memoria flash prácticamente requiere que vacíe un bloque completo antes de que se puedan escribir nuevos datos en el mismo, por lo que [Peter’s] dejaría el contador de versiones en un estado eliminado durante la operación de escritura. Luego, puso el contador de versiones al comienzo del bloque con un truco específico de un rayo: cuando escribió los datos, completó los primeros cuatro bytes con unos (0xFFFFFFFF). Esto coincide con el estado borrado de la memoria flash, lo que le permite volver a los primeros cuatro bytes y escribir el contador de versiones después de que todo el bloque se haya escrito correctamente. Implementación de prueba confiable de [Peter’s] un método de escritura / flash revisado para el ESP8266 se puede encontrar en su blog. ¿Todavía hay demasiado arriba? ¡Háznoslo saber en los comentarios!

• werecatf dice:

  El kernel de Arduino para ESP8266 divide el Flash en dos secciones, una para el boceto y otra para el sistema de archivos SPIFFS. Al realizar una actualización de OTA, almacena el nuevo boceto al final del área de boceto, por lo que debe ser lo suficientemente grande para contener tanto el nuevo como el antiguo al mismo tiempo, establecer una bandera en la memoria RTC y restablecer el ESP8266, luego, el cargador de arranque nota la bandera en la memoria RTC y copia el nuevo boceto sobre el anterior y lo carga como de costumbre. Por lo tanto, toda el área adyacente después del borrador actual está disponible para actualizaciones OTA y no hay fragmentación. El sistema de archivos SPIFFS no se ve afectado en absoluto, lo que permite que su contenido permanezca como estaba.

  • METRO dice:

    ¿Limpio, pero de alguna manera trivial? ¿No podría este método actualizado mejorar el uso de flash?

    • werecatf dice:

      Sí, tal vez sea un poco trivial. Lo compartí como un punto de comparación si alguien lo encontraría interesante.

      La forma en que el kernel de Arduino escribe el boceto de OTA en flash, luego el cargador de arranque lo vuelve a escribir en otra ubicación es un poco derrochador. Funciona, pero escribe inútilmente lo mismo dos veces, desgastando el rayo mucho más rápido.

• StephaneAG dice:

  ¡Hola!
  Si alguien tiene un truco que funcione para permitir la compatibilidad con chips flash de 128M (Winbond W25Q128), me alegrará saberlo; pag
  https://github.com/themadinventor/esptool/issues/123
  http://forum.espruino.com/conversations/279176/?offset=125#comment13202242

  gracias 🙂

• Mate dice:

  Esto casi funciona como usar nivelación en partes de rayos NOR.

• thereza dice:

  No entiendo cómo funcionaría esto. Si actualiza el firmware y la carga muere, solo está garantizando que no haya datos incorrectos en el bloque 4K. Pero la mitad del código puede ser del firmware anterior y la otra mitad del nuevo.

  • pelrun dice:

    No, porque las calculadoras de versiones no se escriben hasta que todos los bloques se cargan correctamente. Y luego, el cargador de arranque puede asegurarse de que todos los contadores de versiones coincidan antes de decidir qué firmware iniciar. Si no es así, simplemente inicie el firmware anterior.

• Cohetes de agua americanos dice:

  ¿Por qué no escriben simplemente un cargador de arranque simple que puede probar el nuevo firmware almacenado en un área flash específica y verificarlo con hash y, si es válido, lo copiará sobre el firmware anterior y luego marcará la actualización como finalizada? Si la actualización falla debido a un ciclo de energía, simplemente se reiniciará y repetirá el proceso hasta que tenga éxito.

  • 4afb dice:

    Ese es exactamente mi método. Mientras parpadea mantiene dos sumas de comprobación actuales (crc32 o md5 sirven), uno rastrea los datos que se escribirán y el otro rastrea los datos leídos del flash. Al final, ambos deben coincidir y solo entonces la operación de flash se considera exitosa y solo entonces la ranura de inicio activa se cambia correctamente. No desperdicie sectores allí, solo verifique lo que ha escrito como antes.

• Blah` dice:

  Thereza: comienza eliminando el número de versión del código que está a punto de reemplazar. Lo último que debe hacer es escribir el nuevo número de versión si todo está marcado. Si algo falla, el otro bloque tiene un número válido y será seleccionado.

  Water Rockets: ¿Qué pasa si falla la energía a la mitad durante la copia de seguridad, no tiene nada ... y no hay forma de volver a descargar, porque el código de descarga estará en el cargador de arranque corrupto?

• It'sThatIdiotAgain dice:

  Oh, la maldición de HAD ataca de nuevo ... "nos ilumina con una mejor solución". => Error al establecer la conexión a la base de datos.
  No importa, supongo que Peter recuperará el sitio pronto.