¿Cuáles son las advertencias de colocar variables PSoC 4 en flash?

Obtuve muy buenos resultados al utilizar la EEPROM emulada de PSoC3, y creo que el componente E_EEPROM es el mismo tanto para PSoC3 como para PSoC4. Aquí están sus respuestas fáciles primero:

1. Sí, los valores se mantendrán persistentes a lo largo de la pérdida de energía, siempre que la pérdida de energía no ocurra durante el ciclo de escritura.

2. No debería tener ningún problema con las variables E_EEPROM que sobrescriben nada. Si está utilizando las macros de Cypress correctamente, el compilador debería ubicar ubicaciones de flash vacías para usted. Sin embargo, no tengo idea de lo que sucede si asigna más variables flash de las que tiene espacio. Espero que el compilador arroje un error para usted, pero no lo he probado.

3. Volvería a revisar su documentación para saber cómo usar realmente la E_EEPROM. El PSoC3 usó el compilador Keil porque el núcleo es en realidad un Intel 8051, a diferencia del núcleo ARM del PSoC4, por lo que es posible que estés en lo correcto. Pero parece más complicado de lo que necesita ser. No tuve que usar ninguna marca de compilación, y el componente EEPROM emulado proporcionó una API mucho más fácil de usar. Además, eche un vistazo a los proyectos de ejemplo que vienen con PSoC Creator.

Aquí está el inconveniente: por lo que sé, usted sí debe preocuparse por la nivelación del desgaste del flash. No pude encontrar ninguna referencia a un esquema automatizado de nivelación de desgaste en los documentos de PSoC3, por lo que supongo que no hay ninguna. Definitivamente, puedes usar tus celdas de Flash con escrituras repetidas, aunque el compilador puede ser lo suficientemente inteligente como para optimizar las escrituras de Flash en tu ejemplo de bucle.

Tenga en cuenta que tampoco necesita escribir en la misma variable para agotar las cosas. En el PSoC3, las filas de flash tienen 256 bytes de ancho. Si tiene una matriz de 32 uint8 y esa matriz se alinea perfectamente con una fila de Flash, escribir en cualquier elemento de la matriz pondrá a toda la matriz a través de un ciclo de lectura-borrado-escritura. El tamaño de fila de PSoC4 puede ser diferente, pero vas a enfrentar la misma situación.

La E_EEPROM fue una solución perfecta para mí cuando necesitaba que los datos permanecieran persistentes en todos los restablecimientos y no tenía la EEPROM real suficiente. Es una buena opción siempre y cuando tenga espacio y tenga cuidado de no desgastar sus celdas Flash.

El componente EEPROM emulado es práctico, y lo he usado para un par de proyectos en los que necesitaba almacenar algunos arreglos de datos bastante grandes entre ciclos de energía. 2 riesgos a tener en cuenta: el arranque y la nivelación del desgaste.

En el encendido (de forma predeterminada), el gestor de arranque PSOC verificará toda la suma de comprobación de la aplicación para comprobar si la imagen de la aplicación es válida o no. Al guardar en flash, está afectando los datos que se suman y tiene una posibilidad de 255 en 256 de "corromper" su imagen flash desde la perspectiva del cargador de arranque. Cypress propone una solución en la que el gestor de arranque puede calcular la suma de comprobación solo durante una actualización de la imagen de inicio. Lo que está bien si no planeas actualizar el PSOC en el campo.

Esto comprometerá la capacidad del cargador de arranque para lanzar una excepción si la imagen realmente ha sido dañada. No es un evento común, sino una mejor alternativa para ejecutar instrucciones fraudulentas desde flash. Mis proyectos particulares incluyeron un PSOC5LP trabajando como un módulo periférico para un sistema de control más grande (ARM Cortex-A). Por lo tanto, mis especificaciones permitieron al sistema, en su conjunto, manejar una excepción de imagen no válida en caso de que suceda.

La solución alternativa que utilicé fue amortiguar los contenidos EEPROM emulados en la RAM en el arranque, usar y modificar los datos durante el tiempo de ejecución y, finalmente, volver a vaciar los arreglos para que parpadeen al apagarse.

Cuando cargué los datos de Em_EEPROM en la RAM en el arranque, la aplicación calculó la suma de comprobación. Los datos luego se usarían y ocasionalmente serían modificados por el código de la aplicación durante el tiempo de ejecución. Cuando escribo de nuevo en la Em_EEPROM al apagar, calculo la suma de control nuevamente, y luego escribo un valor para equilibrar el delta nuevamente en un conjunto de registros flash que había reservado para este mecanismo de verificación y balance.

Al igual que con cualquier código que pueda escribir en flash, tenga mucho cuidado con la nivelación del desgaste. Se recomienda encarecidamente a la diligencia debida desarrollar un mecanismo para limitar escrituras innecesarias. Además, no existe un método 100% a prueba de balas para proteger los datos de la imagen cuando se utiliza el flash de escritura automática. En algún momento, habrá un evento de pérdida de energía que hará que falle una escritura o una serie de escrituras. El código de la aplicación debe tener esto en cuenta y manejar las excepciones en consecuencia.

Como siempre, diseñe dentro de los límites de las especificaciones, los objetivos y las capacidades de su sistema. Si los proyectos en los que he trabajado fueran diseños de MCU independientes, entonces probablemente no habría utilizado los métodos que describí anteriormente. En el contexto de los proyectos tal como fueron diseñados, funcionó con bastante elegancia. Para un sistema PSOC independiente, probablemente hubiera utilizado un medio externo persistente (flash, EEPROM, tarjeta SD, etc.) para mantener el diseño más robusto al evitar el flash de escritura automática.