Hallo Zusammen, ich habe eine kurze Frage zum STM32F4xx (voraussichtlich F429). Habe das Handbuch schon kurz gesichtet aber zum Thema IAP tatsächlich nur einen Glossar Eintrag gefunden. (Wahrscheinlich habe ich nach dem falschen gesucht). Interessant wäre für mich, ob Schreibvorgänge auf den Flash mittels In-Application Programming zur Programmausführung parallelisiert werden können, oder das Programm effektiv still steht solange der Flash beschrieben wird? Könnte man einen externen Flash Speicher ggf. parallel zur Programmausführung beschreiben? Hintergrund ist der, dass während der Programmlaufzeit Daten in den Flash gespeichert werden sollen, eine größere Unterbrechung der Programmausführung oder eine Nichtbehandlung von Interrupts ist aber nicht erlaubt. Vielen Dank!
Defqon schrieb: > Hintergrund ist der, dass während der Programmlaufzeit Daten in den > Flash gespeichert werden sollen, eine größere Unterbrechung der > Programmausführung oder eine Nichtbehandlung von Interrupts ist aber > nicht erlaubt. Der Flashzugriff ist wärend des Schreiben und Löschens meistens nicht möglich aber Cortex-M kann Code aus dem RAM ausführen. Dort müssten dann die Verktortabelle und die wichtigsten Handlerfunktionen samt Unterfunktionen rein.
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.