STM32F4 IAP während Laufzeit

Bei modernen Prozessoren heißt das nicht mehr "IAP", da die 
Programmierung innerhalb und außerhalb der Anwendung gleich abläuft und 
die Unterscheidung hinfällig ist. Bei "ST" nennt sich das daher einfach 
"Flash" bzw. "Flash programming". Schaue daher im Reference Manual im 
Kapitel "3 - Embedded Flash memory interface" nach.

Generell kann man auf den Flash des STM32 nicht lesend zugreifen, 
während eine Schreib/Lösch-Operation läuft. Der F429 aber hat zwei Flash 
Bänke. Dort kann man eine Bank lesen, während man die andere 
programmiert. So kann man das alte Programm ausführen während man das 
neue programmiert, und dann "nahtlos" umschalten.
Alternativ kann man auch den kritischen Code aus dem SRAM ausführen, 
während das Programmieren des Flash läuft. Bei einigen Modellen mit 
FSMC, FMC oder QSPI Interface kann man auch Code aus externem 
Parallel-Flash/RAM, SDRAM, bzw. Seriellem Flash ausführen während der 
interne Flash programmiert wird.

Hallo,

danke für eure Antworten. Das ist also ähnlich wie "Früher" (kenne hier 
nur einen NXPLPC17xx). Hier war ein gleichzeitiges Lesen/Schreiben 
ebenfalls nicht möglich.

Mein Traum wäre es ja gewesen, ich lade die Daten in den RAM, gebe dem 
µC den Befehl "kopiere RAM in Flash" und lasse den µC dann weiterwerkeln 
und rufe irgendwann das Schreibergebnis aus dem µC ab.

Genügend RAM für die gesamte Applikation wird es wohl nicht geben, und 
leider ist es aufgrund der Art der Applikation nicht möglich nur ein 
paar Teile vom Flash in den RAM auszulagern (prinzipiell kann zu jeder 
Zeit immer (fast) alles passieren...).

Wisst ihr in etwa wie lange es mit dem F429 dauert 4kb in den (internen) 
Flash zu schreiben?

Hintergrund ist der, dass während der Applikationslaufzeit (die 
prinzipiell für 24/7 ausgelegt ist) immer wieder mal Daten persistent 
gespeichert werden müssen. Das Problem daran, man kann nie sicher 
voraussagen ob der µC nicht gerade dann irgend eine wichtige Operation 
ausführen muss.

Viele Grüße!

Defqon schrieb:
> Hintergrund ist der, dass während der Applikationslaufzeit (die
> prinzipiell für 24/7 ausgelegt ist) immer wieder mal Daten persistent
> gespeichert werden müssen.
> Viele Grüße!

Sag doch gleich das du garkein Programmupdate machen willst sondern den 
Flash nur als Parameterablage zweckentfremden willst.

EEPROM emulation:
http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF257902
Dein viel größeres Problem die Dauer wird eher die nur begrenzte 
Lebensdauer des Flash-Zellen werden wenn du sie zu oft löschst/neu 
schreibst.

Die Zeiten sind irgendwo im Ref.manual angegeben. Musst du mal suchen 
gehen. Lange dauern tut aber eher das Löschen und nicht das schreiben...


Ich würde für so was eher einen externen EEPROM dranhängen. Denn kannst 
du dann auch ganz gemütlich nebenbei per DMA und z.B.: I2C befüllen. 
Bzw.du musst somit auch nicht blockierend auf das löschen warten.

Hallo,

danke für die Antwort. Ich wollte mir einen Speicheralgorithmus für den 
Flash überlegen der in etwa so ausgesehen hätte:

Initial hätte ich einen 4kb Block (o.ä.) gelöscht.

Diesen Block hätte ich dann so lange sequentiell mit Nutzdaten gefüllt 
(ohne ihn ein weiteres mal zu löschen) bis die 4kb voll gewesen wären. 
Bei 100 byte Nutzdaten hätte ich so etwa 40 mal die Nutzdaten schreiben 
können bevor der 4kb Block effektiv einen (bzw. zwei) Schreibzyklen 
abbekommen hätte.

Wenn der erste 4kb Block voll gewesen wäre ich fortgefahren mit weiteren 
4kb Blöcken z.b. hätte ich davon 16 für diese Aktion reserviert => 16 x 
40 Schreibzyklen.

Wenn der letzte 4kb Block voll gewesen wäre hätte ich wieder beim ersten 
4kb Block von vorne begonnen (wird gelöscht usw.usf...).

Insgesamt hätte ich so 16 x 40 x 10000 Schreibzyklen (ich gehe mal von 
10.000 garantierten Schreibzyklen aus bevor mir der Flash stirbt) zur 
Verfügung. Schreibe ich 1x pro Stunde Nutzdaten hätte ich auf diese 
Weise 6.400.000h Betriebszeit gewonnen => das reicht dicke.

Was haltet ihr von diesen Plan? Er steht und fällt natürlich damit, dass 
man den Flash nur einmal löschen muss und ihn dann sequentiell 
fortlaufend beschreiben kann.

Vielen Dank und Grüße!

> 4kb Block (o.ä.) gelöscht.

Der F4 hat keine 4 KB Sektoren im Flash.
Der hat 4x 16 KB und die restlichen sind 64 oder 128 KB soweit ich mich 
erinnere.

Zini das Wuslon schrieb:

> Der F4 hat keine 4 KB Sektoren im Flash.
> Der hat 4x 16 KB und die restlichen sind 64 oder 128 KB soweit ich mich
> erinnere.

Hi,

dann würde ich natürlich einen passenden Block wählen, z.B. einen 
einzelnen 64 kb Block. Diesen einmalig löschen, sequentiell beschreiben, 
und dann das ganze wieder von vorne. :)

Mir geht es eher darum, ob das im Prinzip so möglich ist? (Ich meine ja. 
So wie ich es verstehe muss der Block nur einmal gelöscht werden, 
programmiert werden kann er dann sequentiell im laufe der Zeit ohne das 
man ihn jedes mal vorher löschen müsste; bin mir aber nicht 100% 
sicher).

Viele Grüße!