¿La CPU de un ARM Cortex M se detiene durante la autoprogramación flash?

La mayoría de las MCU ARM Cortex M no cuentan con memoria EEPROM. En cambio, los datos persistentes se pueden escribir en la misma memoria flash que también contiene el programa.

¿Cuál es el estado de la CPU durante este proceso de borrado / escritura?
¿Se detiene? ¿Mantiene el funcionamiento normal?
¿El comportamiento de la CPU depende de la familia MCU específica (por ejemplo, STM32, Kinetis L) utilizada?

(Para algunas personas, esto podría parecer una pregunta estúpida, pero el PIC16 de Microchip detiene la CPU hasta 40 ms durante la autoprogramación flash).

arm cortex-m

— tiempo real
fuente

¿Tiene referencia sobre el alto PIC16?

— Daniel Grillo

@Wouter ¿Cuáles? ¿Lo has probado, digamos con una interrupción ejecutada completamente en RAM?

— Starblue

Al contrario de lo que comenté antes de leer de sus Manuales de usuario, los chips NXP parecen deshabilitar solo la interfaz flash durante la Programación en la aplicación, por lo que una interrupción que se ejecuta completamente desde la RAM podría ser posible durante el borrado de Flash o el tiempo de escritura. Pero en este territorio en gran parte inexplorado, podría imaginar, por ejemplo, problemas de tiempo cuando la interrupción lleva un tiempo considerable, con consecuencias para la resistencia Flash.

— Wouter van Ooijen

Sí, no tienen eeprom pero, para esta situación, algunos Cortex-M como ST32 tienen un registro de respaldo en el que puede guardar su información allí y sobre PIC16, creo que es algo interesante. por favor mencione su fuente sobre PIC16. (Hoja de datos?)

— Roh

@Wouter Sí, el tiempo podría ser un problema. Excepto para el LPC8xx, los comandos IAP "Copiar RAM a flash" toman la frecuencia del reloj como parámetro, por lo que sospecho que usan un bucle de retardo simple.

— Starblue

El comportamiento del núcleo depende de la implementación. Flash no es parte integral del núcleo ARM y, como tal, cada proveedor lo implementa de manera diferente. Por lo general, durante el proceso de borrado / escritura, uno ejecutaría desde la RAM y la ejecución no debería verse afectada.

En el STM32, creo que las lecturas de bloqueo de flash mientras los ciclos de borrado / escritura están en curso. Esto provocaría que la ejecución del núcleo se detenga hasta que se complete la operación. Con algunas de las configuraciones de flash, creo que puede continuar ejecutando / leyendo flash y solo se detendrá cuando acceda a la parte del flash que está borrando / programando.

He usado otros Cortex M en los que debe ejecutar desde la RAM mientras modifica el contenido de la memoria flash; de lo contrario, se encontrará con una falla del bus (y probablemente un bloqueo del sistema si sus manejadores de fallas de bus / fallas duras están en flash). Algunos micros con grandes cantidades de flash lo implementan como dos arreglos flash independientes, y estos generalmente permiten el acceso completo a un banco mientras operan en el otro.

Debería consultar la documentación de su parte específica para ver las limitaciones de ejecución al modificar el contenido flash.

— rjp
fuente