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

Question

Los chips PSoC4 sólo tienen entre 2 y 4KB de RAM. Eso no es mucho, especialmente si quiero hacer algo de procesamiento de datos. Entre 16 y 32KB de Flash parece mucho más prometedor, incluso si tengo que compartirlo con el código. Gracias al "Flash Accelerator" parece que se puede usar Flash de la misma manera que se usaría la SRAM, sólo a costa de una pequeña caída de rendimiento. Hay un documento que describe cómo hacerlo, y parece bastante trivial:

en Project > Build Settings > Linker > Command Line > Custom Flags añadir:

     -Wl,--section-start=.MY_SECTION=0x00001000

entonces declare su variable como:

     uint8 variable1 __attribute__ ((section(“.MY_SECTION”)));

(es decir, utilizando GCC, como hace PSoC Creator "out of the box").

Ahora bien, si he entendido bien, lo primero que hay que tener en cuenta son los 100k ciclos de escritura que tienen los chips PSoC4 estándar. Realizar 100k escrituras en una variable puede llevar muy poco tiempo; ¿el "acelerador" protege la celda o me arriesgo a dañar el chip con un simple for(uint32 flash_var __attribute__ ((section(“.FLASH”)))=0 ;flash_var<100000;flash_var++){...} ?

A continuación, ¿puedo esperar que la variable mantenga su valor en caso de pérdida de energía, o necesito algún tipo de técnica adicional para obtener esta funcionalidad?

¿Esto juega bien con el bootloader en las aplicaciones que se pueden arrancar, o me arriesgo a sobrescribir el bootloader o algo así?

¿Qué otras consideraciones relativas a ese tipo de variables debería tener en cuenta, en las que no he pensado, y que probablemente sólo aprendería "por las malas" si no pregunto?

Answer 1

Tuve muy buenos resultados usando la EEPROM emulada del PSoC3, y creo que el componente E_EEPROM es el mismo tanto para el PSoC3 como para el PSoC4. Aquí están las respuestas fáciles primero:

1. Sí, los valores permanecerán persistentes a través de la pérdida de energía, siempre y cuando la pérdida de energía no se produzca durante el ciclo de escritura.

2. No deberías tener ningún problema con tus variables E_EEPROM sobreescribiendo nada. Si estás utilizando las macros de Cypress correctamente, el compilador debería localizar las ubicaciones flash vacías por ti. Sin embargo, no tengo ni idea de lo que ocurre si asignas más variables flash de las que tienes espacio. Espero que el compilador arroje un error por ti, pero no lo he probado.

3. Yo revisaría de nuevo su documentación para saber cómo utilizar realmente la E_EEPROM. El PSoC3 utilizó el compilador Keil porque el núcleo es en realidad un Intel 8051, a diferencia del núcleo ARM del PSoC4, así que es posible que tengas razón. Pero parece más complicado de lo necesario. No tuve que usar ninguna bandera del compilador, y el Componente EEPROM emulado proporcionó una API mucho más fácil de usar. Además, echa un vistazo a los proyectos de ejemplo que vienen con PSoC Creator.

Esto es lo malo: Por lo que sé, usted hacer necesita preocuparse por la nivelación del desgaste del flash. No he podido encontrar ninguna referencia a un esquema de nivelación de desgaste automatizado en los documentos de PSoC3, así que asumo que no hay ninguno. Definitivamente puedes desgastar tus celdas Flash con escrituras repetidas, aunque el compilador puede ser lo suficientemente inteligente como para optimizar las escrituras Flash en tu ejemplo de bucle.

Ten en cuenta que tampoco es necesario escribir en la misma variable para desgastar las cosas. En el PSoC3, las filas de la flash tienen 256 bytes de ancho. Si tienes un array de 32 uint8's y ese array se alinea perfectamente con una fila de la Flash, escribir en cualquier elemento del array va a hacer que todo el array pase por un ciclo de Lectura-Frase-Escritura. El tamaño de la fila del PSoC4 puede ser diferente, pero te vas a encontrar con la misma situación.

La E_EEPROM fue una solución perfecta para mí cuando necesitaba que los datos permanecieran a través de los reinicios, y no tenía suficiente EEPROM real. Es una buena opción siempre y cuando tengas el espacio necesario y tengas cuidado de no desgastar tus celdas Flash.

Answer 2

El componente EEPROM emulado es útil, y lo he utilizado para un par de proyectos en los que necesitaba almacenar algunas matrices de datos bastante grandes entre ciclos de energía. Hay que tener cuidado con dos escollos: La carga de arranque y el nivel de desgaste.

En el encendido (por defecto), el gestor de arranque PSOC comprobará la suma de comprobación de la aplicación en la flash para comprobar si la imagen de la aplicación es válida o no. Al guardar en la flash, está afectando a los datos que se suman y tiene una probabilidad de 255 en 256 de "corromper" su imagen flash desde la perspectiva del gestor de arranque. Cypress propone una solución en la que el gestor de arranque se ve obligado a calcular la suma de comprobación sólo durante una actualización de la imagen de arranque. Lo cual está bien si no planeas actualizar el PSOC en el campo.

Esto comprometerá la capacidad del gestor de arranque para lanzar una excepción si la imagen ha sido realmente corrompida. No es un evento común, pero es una mejor alternativa a la ejecución de instrucciones falsas desde la flash. Mis proyectos particulares involucraban un PSOC5LP trabajando como un módulo periférico a un sistema de control más grande (ARM Cortex-A). Así que mis especificaciones permitieron que el sistema, como un todo, manejara una excepción de imagen inválida en caso de que sucediera.

La solución que utilicé fue almacenar el contenido de la EEPROM emulada en la memoria RAM durante el arranque, utilizar y modificar los datos durante el tiempo de ejecución y, finalmente, vaciar las matrices de nuevo en la memoria flash al apagar.

Cuando cargué los datos de la Em_EEPROM en la RAM en el arranque, la aplicación calculó la suma de comprobación. Los datos serían entonces utilizados y ocasionalmente modificados por el código de la aplicación durante el tiempo de ejecución. Cuando escribía de nuevo en la Em_EEPROM al apagar, calculaba de nuevo la suma de comprobación y luego escribía un valor para equilibrar el delta en un conjunto de registros flash que había reservado para este mecanismo de comprobación y equilibrio.

Al igual que con cualquier código que pueda escribir en flash, hay que ser muy, muy consciente de la nivelación del desgaste. Se recomienda encarecidamente desarrollar un mecanismo para limitar las escrituras innecesarias. Además, no existe un método 100% a prueba de balas para proteger los datos de la imagen cuando se utiliza una memoria flash de auto-escritura. En algún momento, habrá un evento de pérdida de energía que hará que una escritura o una serie de escrituras fallen. 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, objetivos y capacidades de su sistema. Si los proyectos en los que he trabajado fueran diseños de MCU independientes, probablemente no habría utilizado los métodos que he descrito anteriormente. En el contexto de los proyectos tal y como fueron diseñados, funcionó con bastante elegancia. Para un sistema autónomo PSOC, probablemente habría utilizado un medio externo persistente (flash, EEPROM, tarjeta SD, etc.) para mantener el diseño más robusto evitando la auto-escritura de flash.