Le processeur d'un ARM Cortex M s'arrête-t-il pendant l'auto-programmation flash?

La plupart des MCU ARM Cortex M ne disposent pas de mémoire EEPROM. Au lieu de cela, les données persistantes peuvent être écrites dans la même mémoire flash qui contient également le programme.

Quel est l'état du CPU pendant ce processus d'effacement / écriture?
Est-ce que ça s'arrête? Maintient-il un fonctionnement normal?
Le comportement du CPU dépend-il de la famille MCU spécifique (par exemple STM32, Kinetis L) utilisée?

(Pour certaines personnes, cela pourrait ressembler à une question stupide, mais le PIC16 de Microchip arrête le processeur jusqu'à 40 ms pendant l'auto-programmation flash.)

arm cortex-m

— temps réel
source

Avez-vous une référence à l'arrêt PIC16?

— Daniel Grillo

@Wouter Lesquels? L'avez-vous testé, disons avec une interruption entièrement exécutée en RAM?

— starblue

Contrairement à ce que j'ai commenté avant de lire leurs manuels d'utilisation, les puces NXP semblent désactiver uniquement l'interface flash pendant la programmation d'application, donc une interruption qui s'exécute entièrement à partir de la RAM peut être possible pendant l'effacement ou l'écriture de Flash. Mais sur ce territoire largement inexploré, je pourrais par exemple imaginer des problèmes de timing lorsque l'interruption prend un temps conséquent, avec des conséquences sur l'endurance Flash.

— Wouter van Ooijen du

Oui, ils n'ont pas d'eprom mais, pour cette situation, certains Cortex-M comme ST32 ont un registre de sauvegarde sur lequel vous pouvez enregistrer vos informations là-bas et sur PIC16, je pense que c'est une chose intéressante. veuillez mentionner votre source sur PIC16. (Fiche technique?)

— Roh

@Wouter Oui, le timing pourrait être un problème. Sauf pour le LPC8xx, les commandes IAP "Copier RAM pour flasher" prennent la fréquence d'horloge comme paramètre, donc je soupçonne qu'elles utilisent une simple boucle de retard.

— starblue

Le comportement du noyau dépend de l'implémentation. Le Flash ne fait pas partie intégrante du cœur ARM, et en tant que tel, chaque fournisseur l'implémente différemment. En règle générale, pendant le processus d'effacement / d'écriture, on exécuterait à partir de la RAM, et l'exécution ne devrait pas être affectée.

Sur le STM32, je crois que les lectures à partir du décrochage flash pendant que les cycles d'effacement / écriture sont en cours. Cela entraînerait le blocage de l'exécution du cœur jusqu'à la fin de l'opération. Avec certaines configurations de flash, je pense que vous pouvez continuer à exécuter / lire le flash et il ne se bloquera que lorsque vous accéderez à la partie du flash que vous effacez / programmez.

J'ai utilisé d'autres Cortex M où vous devez exécuter à partir de la RAM tout en modifiant le contenu du flash, sinon vous rencontrerez une panne de bus (et probablement un plantage du système si vos gestionnaires de pannes de bus / de pannes matérielles sont en flash). Certains micros avec de grandes quantités de flash l'implémentent comme deux baies flash indépendantes, et celles-ci permettent généralement un accès complet à une banque tout en fonctionnant sur l'autre.

Vous devrez vous référer à la documentation de votre partie spécifique pour voir les limitations de l'exécution lors de la modification du contenu flash.

— rjp
source