Daten ins Flash speichern mit dem STM32

Erstmal musst du im Linker File eine neue Section anlegen, die du für 
die Nutzdaten verwendest ( ich denke eine Memory Page wird dafür locker 
reichen ).
Die Variable wird in diese Section gepackt und kann auch schon 
problemlos gelesen werden.
Um sie zu beschreiben, musst du
1) Flash unlocken
2) Die ganze Page löschen
3) Die Variable beschreiben
4) Flash wieder locken
(für jeden diese Punkte gibt es im FLASH teil der Std Lib Funktionen)
So hat es bei mir zumindest unter CooCox schonmal funktioniert.

Da man den Flash nur seitenweise beschreiben kann, muss man eine 
komplette memory page für die Nutzdaten reservieren.
Die Größe und Adresse der pages entnimmst du dem Reference Manual.
In meinem Fall ( STM32F103C8 ) waren es 64 pages a 1K, ab 0x08000000.
D.h. die letzte Page ( die ich für Daten benutze ) fängt bei 0x0800FC00 
an.

Das Linker Script besteht aus 2 Teilen ( meist in den Dateien memory.ld 
und/oder link.ld ... je nach Entwicklungsumgebung ):
1) MEMORY Definition:

1

MEMORY

2

{

3

  rom (rx)  : ORIGIN = 0x08000000, LENGTH = 0x0000FC00

4

  rom1 (rx)  : ORIGIN = 0x0800FC00, LENGTH = 0x00000400

5

  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00005000

6

}

Hier wird das vorhandene Memory festgelegt.
rom ist in diesem Fall das restliche Flash ( Pages 1-63 ) und rom1 die 
letzte memory page, die für die Daten verwendet wird.

2) Section Definition:

1

SECTIONS 

2

{

3

    .mydata :

4

    {

5

        *(.mydata)

6

    } > rom1

7

[...]

8

}

Hier wird eine Section namens .mydata definiert, sodass alle Variablen, 
welche in diese Section wandern im Memory Bereich rom1 landen.

Zu guter letzt wird die Variable in die section .mydata gepackt:

1

__attribute__ ((section(".mydata")))

2

volatile uint8_t meineDaten = 0;

ok, danke für den Tip! Ich hoffe ich kapier es bald :-)

Das Ziel ist, dass einmal am Tag die Zurückgelegte Strecke abgespeichert 
wird und mittels Service -Kit per CAN ausgelesen werden kann.

Also Ich muss immer

das Flash unlocken,
die page löschen,
die Variable beschreiben,
das flash locken.

Der Linker setzt die Variable dann automatisch an nullter Stelle im 
Flash, so muss ich also auch nur die page 0 löschen?

Gibt es eine Kontrollmöglichkeit, um sicher zu sein, dass es geklappt 
hat?
Gewisse teilen ja den Flashbereich und speichern alles doppelt?

Danke und Gruss!

M. B. schrieb:
> Der Linker setzt die Variable dann automatisch an nullter Stelle im
> Flash, so muss ich also auch nur die page 0 löschen?

Der Linker setzt sie nicht an Stelle 0, dort liegt der Einstiegspunkt in 
dein Hauptprogramm. Vom Löschen von Page 0 ist DRINGEND abzuraten.
Es stimmt, man kann auch ohne Sections arbeiten, allerdings besteht dann 
halt die Gefahr, dass auf der Page, auf der man arbeitet, weitere Daten 
abgelegt werden. Aber wie Gebhard Raich (geb) gesagt hat, ist das eher 
unwahrscheinlich.
Die saubere Lösung wäre natürlich, alles fein säuberlich in Sections 
aufzuteilen, damit nichts passieren kann. Für den Testbetrieb kann man 
das aber auch weglassen.

> Gibt es eine Kontrollmöglichkeit, um sicher zu sein, dass es geklappt
> hat?
Naja, wenn es funktioniert, weisst du es ;)
Du kannst dir die map-File ansehen, die der Compiler erstellt. Darin 
stehen die Adressen aller deiner Variablen nachdem der Linker sie 
verteilt hat.

Als erstes solltest du rausfinden wie viele pages dein Controller hat 
und wie groß diese sind.
Dann suchst du die Adresse der letzten page raus und probierst 
testweise, dort daten abzulegen und auszulesen. Wenn das klappt, kannst 
du dich immer noch um das Sectioning kümmern wenn du willst.

Hier auch mal ein einfaches, aber funktionierendes Beispiel:

1

uint32_t data = 0xFFCCAA99;

2

3

...

4

5

  FLASH_Unlock();

6

  FLASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR);

7

  FLASH_ErasePage(0x0800FC00);

8

  FLASH_ProgramWord(0x0800FC00, data);

9

  FLASH_Lock();

Hier wird die Seite beginnend bei 0x0800FC00 gelöscht und an der Stelle 
0x0800FC00 werden 4 byte geschrieben ( der Inhalt der Variable data ).
Man könnte nun mittels eines Zeigers darauf zugreifen:

1

uint32_t *pData = 0x0800FC00;

2

3

printf("%d", *pData);

M. B. schrieb:
> jetzt habe ich alle Daten, die ins Flash gehören in einn Struct gefasst.

> Ich muss jetzt aber alle Variablen einzeln ins flash laden und jede
> Variable kommt in eine neue Page, hab ich das richtig verstanden?

Ich habe es anders verstanden (FLASH_ErasePage z.B. habe ich im zip aber 
auch nicht gefunden).
Statt FLASH_ProgramWord kann man ja bestimmt auch eine ganze page 
schreiben. Oder in einer Schleife ein word nach dem anderen. 
Wahrscheinlich gibt es auch eine Funktion, mit der man einen Block mit 
variabler Größe schreiben kann. Oder schreibt sich die, wie gerade 
beschrieben, mit einer Schleife selbst.

Lutz schrieb:
> Oder in einer Schleife ein word nach dem anderen.

Genau so wird das gemacht.
Dein Struct schreibst du Word für Word in diese eine Page, hast ja 2KB 
Platz.
Ansonsten wäre das ja ein ziemlich großer Flashverbrauch.

Die Lib hat nur Funktionen zum schreiben von Word und HalfWord.

M. B. schrieb:
> Zum Daten aus dem Flash laden, gibts da keinen Read
> Befehl?

Nein, weil es ja mittels Pointern ziemlich einfach ist ( siehe oben ).
Wenn du eine Linker Section für die Variable hinbekommst, kannst du sie 
sogar ganz regulär lesen.

Im Datenblatt steht wahrscheinlich "up to 255 Pages" ...
Also hast du nur 192 Seiten a 2kB, was dann deine 384kB ergibt.

Die Adresse 0x0807F800 wäre die Startadresse der page 255.
Weil dein Controller aber nur 192 pages hat, ist die Adresse der letzten 
Seite 0x0805F800 ( = 0x08000000 + 191 * 2048 ).

Also, dein Controller ist laut Datenblatt aus der High-density 
performance line.
Von dem gibt es mehrere Versionen, z.B. deine STM32F103VDT6 mit 384 kB 
Flash oder auch STM32F103VET6 mit 512 kB Flash ( nur das E ist hier in 
der Bezeichnung anders ).
Nun könnten ST zu jeder dieser Versionen eine eigene Tabelle machen, das 
wäre aber zu viel Arbeit.
Daher geht man im Reference Manual von der Vollbestückung ( in diesem 
Fall 512 kB ) aus, für alle anderen Modelle muss man ein wenig rechnen.

In Abschnitt 3.3.3 vom Reference Manual steht:

1

Memory organization: the Flash memory is organized as a main block and an 

2

information block:

3

[...]

4

up to 64 Kb × 64 bits divided into 256 pages of 2 Kbytes each (see Table 6) for 

5

high-density devices

6

[...]

Also wieder das "up to".
Da dies 512 kB Flash entsprechen würde, musst du halt deine 192 Pages a 
2 kB selbst ausrechnen und kommst wie oben erklärt zur Adresse der 
letzten page.
Die wichtigsten Informationen hier sind nur die page size und der Start 
( 0x08000000 ). Den Rest kann man dann selbst berechnen.

M. B. schrieb:
> void set_in_Flash(tSetup2 *setup)
> {
>
>   uint32_t *pData = (uint32_t *)setup;
>   uint8_t i;
>   int x = (sizeof(tSetup2) / sizeof(int));
>
>   FLASH_Unlock();
>   FLASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP | FLASH_FLAG_PGERR | 
FLASH_FLAG_WRPRTERR);
>   FLASH_ErasePage(FLSHBSEADRPG192);
>
>   for(i=0;i<x;i++)
>   {
>     FLASH_ProgramWord(FLSHBSEADRPG192, pData[i]);
>   }
>   FLASH_Lock();
>
> }

Kein wunder, du schreibst alle deine Daten an die selbe Adresse.

1

FLASH_ProgramWord(FLSHBSEADRPG192 + i*sizeof(uint32_t), pData[i]);

AVerr schrieb:
> Kein wunder, du schreibst alle deine Daten an die selbe Adresse.
> FLASH_ProgramWord(FLSHBSEADRPG192 + i*sizeof(uint32_t), pData[i]);
                                    ^^^^
Sicher?

Frage: Versuchst du mit pData[i] auf ein struct-member zuzugreifen?

Etwas Ordnung bzw. Weitblick sollte dazu führen, daß du eine globale 
volatil-Variable (man weiß ja nie, was noch dazukommt oder wo man es 
noch nutzt) einführst, die dir die nächste freie Speicherstelle in 
deiner section anzeigt. Sinnvollerweise muß die natürlich selbst in die 
section deines Flash gelegt werden, um auch nach einem reset noch ihre 
Funktion erfüllen zu können; so quasi als Inhaltsverzeichnishilfe.
Da fällt einem bei Nachdenken sicher noch etwas mehr sinnvolle Struktur 
für diese section ein ...

Roland H. schrieb:
> Zwischen dem BOOL und dem ersten int ist vermutlich ein Loch von 3 Byte.
Wenn BOOL hier als uint8_t definiert ist, ja. Also sollte man ... oder 
... .

Was du brauchst, ist die definierte Pageadresse(n). Ich würde immer das 
Ende vom Flash dafür nutzen.

Eine Page ist je nach Device entweder 1KByte oder 2KByte groß. Dem 
linker musst du nicht beibringen, sondern "nur" in deinem Programmcode 
auf die gewünschte Page zugreifen. So in der Art:

1

int i;

2

uint16_t data = 0;

3

FLASH_Unlock();

4

5

// Clear Flags

6

FLASH_ClearFlag(FLASH_FLAG_EOP|FLASH_FLAG_PGERR|FLASH_FLAG_WRPRTERR);

7

8

FLASH_ErasePage(0x0801F000);

9

10

for (i = 0; i < 512; i++) {

11

 FLASH_ProgramHalfWord(0x0801F000 + (i * 2), (uint16_t)(0x00FF & data));

12

 data++;

13

}

Also recht simpel.

Ach ja und beim Download "Erase affected" Option verwenden, so wird beim 
Programmieren nur der beschriebene Bereich des uC's gelöscht.

Ich hänge mich mal hier an.

Das folgende:

1

uint32_t *pData = 0x0800FC00;

2

3

printf("%d", *pData);

funktioniert beim STM32F4 NICHT. Ich bekomme dort völlig irrationale 
Werte.

Gibt es bei der F4 Serie eigene Lesebefehle von ST?

Ich habe so etwas ähnliches bereits realisiert, da mir das EEPROM 
Emulation Beispiel von ST nicht wirklich gefallen hat. Ich teile es 
gerne. Eine Beschreibung ist nicht dabei und ist nicht ausgiebig auf 
Bugs getestet. Gespeichert wird ein Byte/Word im Flash, um die 
Überschreibzyklen zu reduzieren, also bei einer Page von 1024 Byte 
stehen 512 Bytes zu Verfügung.

Das kann doch nicht funktionieren. Woher weiss der Compiler denn, dass 
ich mit "0x0800FC00" eine Adresse meine? Gibt es keine Spezielle 
Lesefunktion beim STM32F4? Page und solche Dinge gibt es beim F4 nicht.

Ich will aber nicht die Variablen in so eine selbst definiert Sektion 
schreiben, sondern aus beliegen Speicherstellen lesen können, um Z.B 
zeigen zu können, dass mein Flashvorgang geklappt hat. Und um Linkerfile 
schreibt die Keil IDE schon herum. Vielleicht kann ich da in den 
Einstellungen etwas übergeben. Ok, mal sehen...

Hallo zusammen,

ich beschäftige mich momentan auch damit, Daten während der Laufzeit in 
den Flash-Speicher zu schreiben.

Ich verwende einen STM32F429 mit der Entwicklungsumgebung µVision und 
dem Compiler von Keil.

Ich schreibe Daten aus einem Array ab einer bestimmten Adresse im 
Flash-Speicher.
Ich schreibe die Daten dazu Wort für Wort in den Speicher ohne vorher 
den Speicherbereich zu löschen.
Er beschreibt auch die gewünschten Adressen allerdings sind die Daten im 
Flash verändert gegenüber den Werten im Array.

Beispielsweise soll 0xC8 geschrieben werden und im Flash-Speicher steht 
0xC0 oder 0x48 oder statt eines Wertes 0x1AC2 (Array) steht 0x1A82 im 
Flash-Speicher. Also irgendwie scheinen die Werte leicht verändert zu 
sein.

Folgender Code verwende ich zum Schreiben der Daten:

/* Enable the flash control register access */
FLASH_Unlock();

/* Calculate the end address */
u32l_start_address = u32param_start_adr;
u32l_end_address = u32param_start_adr + u32param_length;

/*Check if the start-address is valid */
if (u32l_start_address >= ADDR_FLASH_START)
  {
  /*Check if the end-address is valid */
  if (u32l_end_address <= ADDR_FLASH_END)
    {
    /* Program the user Flash area word by word */
    while (u32l_start_address < u32l_end_address)
      { /* Write data to flash */
      if (FLASH_ProgramWord(u32l_start_address, *u32param_data) == 
FLASH_COMPLETE)
        { /* Increment address to write */
        u32l_start_address = u32l_start_address + 4;
        /* Increment the address of the data field to save */
        u32param_data++;
        }
      else
        {
        /* Error occurred while writing data in Flash memory, set error 
*/
        u32l_error_code = ERR_WRITING_FLASH;
        }
      }
    }
  else
    {
    /* Illegal end-address, set error*/
    u32l_error_code = ERR_END_ADR_FLASH;
    }
  }
else
  {
  /* Illegal start-address, set error*/
  u32l_error_code = ERR_START_ADR_FLASH;
  }

/* Lock the Flash to disable the flash control register access 
(recommended
   to protect the FLASH memory against possible unwanted operation) */
FLASH_Lock();

Also das Schreiben auf die Adressen klappt, und die Adressen stimmen 
auch, lediglich stimmt der Inhalt nicht.

Ich würde mich über alle Hilfen freuen.

Grüße vom Flasher

Hallo Martin,

vielen Dank für deine Antwort, sowas habe ich mir schon gedacht, 
allerdings ist es blöd einen ganzen Sektor zu löschen, ich würde gerne 
nur Teile eines Sektors löschen.
Doch in der Standardbiblithek habe ich noch keine derartige Funktion 
gefunden.
Den gewünschten Speicherbereich mit Nullen zu beschreiben wird nicht 
gehen oder?

Oder gibt es eine Möglichkeit einen Speicherbereich von  z.B. 100Bytes 
zu löschen?

Grüße

der Flasher

Flasher schrieb:
> Oder gibt es eine Möglichkeit einen Speicherbereich von  z.B. 100Bytes
> zu löschen?

Nein, nur ganze Pages sind möglich! Warum stört Dich das Löschen??

Hi Flasher,

Du kannst problemlos jeden "gewünschten Speicherbereich mit Nullen zu 
beschreiben".

Weiterführende Tipps, z.B. wie man auch wieder 1en in die Sektoren 
bekommt, findest Du in den Handbüchern (RM0090 oder auch in AN3969).

Grüße,
 RoyalFlush

Hallo Sepp,

die Pages sind 128kByte groß (zumindest die im oberen Speicherbereich) 
ich verwende aber für verschiedene Daten verschiedene Bereiche 
(Konfigurationsdaten, Fehler, Logging-Daten und Zeitdaten, etc.) wenn 
ich jetzt in einen Sektor mehrere Daten ablegen will, will ich davor ja 
nicht alle Daten wieder löschen.
Und so viele Datenarten und Code wie ich verwende, gibts nun mal nicht 
genügend Sektoren.

Natürlich kann ich kleinere Sektoren verwenden, aber die kleinsten haben 
nun mal auch min. 16kByte.

Oder gibt es noch ne andere Lösung für meine Daten?

Grüße

der Flasher

Hallo Martin,

also soweit alles verstanden, was die Speicherung betrifft.

Jetzt habe ich nur folgendes Problem: Ich möchte die kleinsten Sektoren 
des Flash-Speichers benutzen (Sektor0 bis Sektor3 mit jeweils 16kB und 
Sektor4 mit 64KB)
Das Programm beginnt momentan bei 0x08000000, jetzt habe ich in der 
µVision-Umgebung den Beginn des Programms auf 0x08020000 verschoben, die 
Länge angepasst im Programm habe ich das Headerfile angepasst, in dem 
beispielsweise Definitionen zum Flash-Speicher-Start und zum Ort der 
Vektortabelle angegeben sind ebenfalls auf die neue Adresse des 
Programmcodes angepasst.

Aber jetzt läuft mein Programm gar nicht mehr, wenn ich es wieder 
zurückstelle geht es wieder.

Was muss ich beachten um mein Programm (meine Interrupt-Vektortabelle) 
im Speicher nach hinten in den ersten 128kB-Sektor zu schieben?
Hab ich noch was vergessen, oder geht es ganz anders?

Grüße

der Flasher

Hallo zusammen,

wenn Daten überschrieben werden sollen, die z.B. in der Mitte einer Page 
liegen, davor befindliche Daten aber erhalten bleiben sollen, müssen 
dann alle zu erhaltenden Daten zunächst zwischengespeichert werden und 
nach dem Erase wieder geschrieben werden?

Grüßle

Hm... ich war "ideelich" auf dem Weg da eine Art FAT System anzulegen 
ähnlich wie bei SD Karten, aber da rappelt man sich ja nen Ast mit den 
Lösch und Schreibzugriffen...

Ich tausche die letzten 8 Pages meine Flashes gegen 16kiB internes 
EEPROM - jemand interessiert^^

Sorry für's Ausgraben dieses alten Beitrags, aber es passt hier genau 
dazu, es geht um den Ausschnitt aus dem Linkerscript oben:

1

  rom (rx)  : ORIGIN = 0x08000000, LENGTH = 0x0000FC00

2

  rom1 (rx)  : ORIGIN = 0x0800FC00, LENGTH = 0x00000400

3

  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00005000

Gibt es eine Möglichkeit eine eigene Section zu definieren, die Mitten 
in einer anderen liegt, so dass die andere Section sich drumherumlegt? 
Gemeint ist das so:

1

  rom (rx)  : ORIGIN = 0x08000000, LENGTH = 0x0000FE00

2

  rom1 (rx)  : ORIGIN = 0x08001000, LENGTH = 0x00000100

3

  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00005000

Sinn ist dass ich ein paar Variablen an eine feste Adresse im Hexfile 
bekomme, so dass ich "von außen" (etwa in einem Firmwareupdatetool) z.B. 
die Version aus der Datei lesen kann. Wennn man rom1 ans Ende legt, hat 
man immer eine bin-Datei die so groß wie das Flash ist und zwischen der 
Applikation und dem rom1 Bereich ist alles leer.

Stefan