La CPU di un ARM Cortex M si arresta durante l'autoprogrammazione del flash?

La maggior parte delle MCU ARM Cortex M non dispongono di memoria EEPROM. Invece, i dati persistenti possono essere scritti nella stessa memoria flash che contiene anche il programma.

Qual è lo stato della CPU durante questo processo di cancellazione / scrittura?
Si ferma? Mantiene il normale funzionamento?
Il comportamento della CPU dipende dalla famiglia MCU specifica (ad es. STM32, Kinetis L) utilizzata?

(Per alcune persone potrebbe sembrare una domanda stupida, ma PIC16 di Microchip blocca la CPU fino a 40 ms durante l'autoprogrammazione flash.)

arm cortex-m

— tempo reale
fonte

Hai riferimenti sulla fermata PIC16?

— Daniel Grillo,

@Wouter Quali? L'hai provato, diciamo con un interrupt interamente eseguito nella RAM?

— Starblue

Contrariamente a quanto ho commentato prima di leggere dai loro Manuali, i chip NXP sembrano disabilitare solo l'interfaccia flash durante la programmazione dell'applicazione, quindi un interruzione che viene eseguito interamente dalla RAM potrebbe essere possibile durante la cancellazione Flash o il tempo di scrittura. Ma in questo territorio in gran parte non esplorato, per esempio, potrei immaginare problemi di temporizzazione quando l'interruzione richiede tempo sostanziale, con conseguenze per la resistenza di Flash.

— Wouter van Ooijen,

Sì, non hanno eeprom ma, per questa situazione alcuni Cortex-M come ST32 hanno un registro di backup in cui è possibile salvare le informazioni su lì e su PIC16, penso che sia una cosa interessante. per favore, menziona la tua fonte su PIC16. (Foglio dati?)

— Roh

@Wouter Sì, i tempi potrebbero essere un problema. Ad eccezione di LPC8xx, i comandi IAP "Copia RAM per flash" prendono la frequenza di clock come parametro, quindi sospetto che utilizzino un semplice loop di ritardo.

— Starblue,

Il comportamento del core dipende dall'implementazione. Flash non è parte integrante del core ARM e, come tale, ogni fornitore lo implementa in modo diverso. In genere, durante il processo di cancellazione / scrittura si dovrebbe eseguire dalla RAM e l'esecuzione non dovrebbe essere influenzata.

Sull'STM32, credo che legga dallo stallo del flash mentre sono in corso i cicli di cancellazione / scrittura. Ciò causerebbe l'interruzione dell'esecuzione del core fino al completamento dell'operazione. Con alcune configurazioni del flash, credo che tu possa continuare a eseguire / leggere il flash e si bloccherà solo quando accedi alla parte del flash che stai cancellando / programmando.

Ho usato altri Cortex M in cui è necessario eseguire dalla RAM mentre si modificano i contenuti flash, altrimenti si verificherà un errore del bus (e probabilmente un arresto anomalo del sistema se i gestori di errori del bus / errore grave sono in flash). Alcuni micro con grandi quantità di flash lo implementano come due array di flash indipendenti e in genere consentono l'accesso completo a un banco mentre si opera sull'altro.

Dovresti fare riferimento alla documentazione per la tua parte specifica per vedere i limiti di esecuzione durante la modifica dei contenuti flash.

— RJP
fonte