STM32 + Nichtflüchtiger Speicher

Was ich noch vergessen habe:
Mir würden schon wenige Bytes( < 10 ) reichen.

Ich hätte 3 Ansätze:

- 1 IO-Pin = 3 Zustände GND/VCC/Offen
- 1 ANA-IN Pin und da über einen Spannungsteiler (2 Winderstände) einen 
Wert vorgeben
- Beim STM32F2xx / F4xx gibt es 512 Byte OTP (Siehe Refman 2.3.3)

Ansonsten den oberen Flash-Bereich belegen und nur selektiv die 
Fals-Bereiche löschen, kein Chip-Erase, das sollte die Update-Funktion 
halt können.

Hallo Uwe,

ich schau mir die AN2594 grad an. Aber sind die Daten dann auch nach dem 
Flashen vorhanden?

Ja.

Ein STM32L1xx hat ein EEPROM drin, falls der eingesetzt werden könnte.

Markus Müller schrieb:
> Ja.
>
> Ein STM32L1xx hat ein EEPROM drin, falls der eingesetzt werden könnte.

Leider nicht. es besteht schon hardware. Also die Lösung sollte auf 
basis des STM32F1xx gefunden werden.

Im VBATT gepufferten SRAM?
Wenn der Update gemacht wird, so nimmt die Software diesen Inhalt und 
kopiert den wieder ins Flash, sofern dort FFFFFF drin steht.

Das geht ohne externe Devices und ohne das Flash bemühen zu müssen. In 
den Option Bytes der STM32F1xx, die ansonsten für Read/Write-Protection 
zuständig sind, stehen 2 frei programmierbare Bytes für die Anwendung 
zur Verfügung. Mehr dazu siehe "PM0075 - Programming manual".

A. K. schrieb:
> Das geht ohne externe Devices und ohne das Flash bemühen zu müssen. In
> den Option Bytes der STM32F1xx, die ansonsten für Read/Write-Protection
> zuständig sind, stehen 2 frei programmierbare Bytes für die Anwendung
> zur Verfügung. Mehr dazu siehe "PM0075 - Programming manual".

Also ich bin grad dabei das Auszuprobieren. Kann ich mich da aus dem µC 
aussperren oder was kaputt machen wenn ich da irgendeinen quatsch 
reinschreibe?
Bleib dieser Speicher auch nach dem Flashen erhalten?

Ich kenne davon auch nur die Doku.

Keine praktische erfahrung damit? :)

Weshalb willst du unbedingt irgendeinen Quatsch reinschreiben?

Will ich nicht. Ich will nur wissen ob ich den uC austauschen darf wenn 
ich da was falsches rein schreibe :)

Wenn du den seriellen Flash Loader Demonstrator dafür verwendest und mit 
load-modify-apply arbeitest, dann musst du m.E. schon mit Vorsatz 
vorgehen, um Probleme zu bekommen.

So viel ich weiß kann man mit der integrierten Bootloader (z.B. UART1) 
und entsprechenden Setzen der Boot-Pins immer einen Flash-Komplett erase 
machen.

Tarkan D. schrieb:

> Bleib dieser Speicher auch nach dem Flashen erhalten?

Ich nehme an ja, da "mass erase" und "option byte erase" getrennte Bits 
im Steuerregister verwendet. Aber häng den erwähnten seriellen Flash 
Loader dran und probier es aus.

Der kann die übrigens sogar per command line einzeln programmieren.

Mit dem "STM32 ST-LINK Utility" von ST kann man alles getrennt 
programmieren. Damit sollte man am einfachsten das ganze testen können.

Als Kommandozeile sollte dann das Tool "ST-LINK_CLI.exe" verwendet 
werden.

Die grafische Oberfläche "STM32 ST-LINK Utility.exe" hat die 
Command-Line Parameter nicht.

Vielen Dank für die vielen Antworten.

Ich muss mein Problem etwas genauer eingrenzen. Ich hab leider vergessen 
zu sagen dass ich die Bytes während der Programmlaufzeit beschreiben 
will.

Also:
1. Ich möchte eine Software schreiben die ich auf meine Karte flashe.
2. Nachdem das geschenen ist möchte ich über USB oder sonst was ein paar 
bytes empfangen.
3. diese Bytes sollen nun von meiner schon draufgeflashten software 
irgendwo hingeschrieben werden, sodass sie nach einem reset nicht 
verloren gehen.Auch ein erneutes flashen über jtag sollte diesen wert am 
besten nicht überschreiben.
4. mein programm sollte diese bytes problemlos auslesen können.

was ich schon habe:

1

    uint32_t COPY_OF_FLASH_OBR, FLASH_OBR_MASK; //Buffer für das Register

2

3

    unsigned char FLASH1,FLASH2;  // Bytes anlegen die geschrieben werden sollen

4

5

    COPY_OF_FLASH_OBR = *(__IO uint32_t*)(0x4002201C);  // inhalt des optionbyte registers holen

6

    FLASH_OBR_MASK = 0xFC0003FF;  // maske damit nur die richtigen bytes verändert werden

7

    COPY_OF_FLASH_OBR &= FLASH_OBR_MASK; // nur die relevanten bytes werden gelöscht

8

    FLASH1 = 0x00;FLASH2 = 0x00;  // testweise sollen die beiden bytes den wert 0 haben

9

    COPY_OF_FLASH_OBR |= ( (uint32_t)(FLASH1<<10) | (uint32_t)(FLASH2<<18) );  // verändern des buffers

10

    *(__IO uint32_t*)(0x4002201C) = COPY_OF_FLASH_OBR;  // zurückschreiben

11

    COPY_OF_FLASH_OBR = *(__IO uint32_t*)(0x4002201C);  //erneutes auslesen des registers

wer hätte es gedacht, es funktioniert nicht. wäre auchzu schön gewesen.

manche werden sich an den kopf fassen, andere evtl. lachen.

Leider hab ich keine ahnung wie ich es sonst anstellen soll :S

Jetzt verstehe ich deine Frage oben. Wenn man einfach mal rumprobiert 
ohne weder vorher noch nachher auch nur eine einzige Zeile Doku zu 
lesen...

Steht alles im PM0075 drin.

Ein Flash kann beschreiben werden wenn er zuvor mit der Unlock-Sequenz 
entsperrt wird.

Details stehen im Flash Programming Manual.

Tarkan D. schrieb:

1

    uint32_t COPY_OF_FLASH_OBR, FLASH_OBR_MASK; //Buffer für das Register

2

3

    unsigned char FLASH1,FLASH2;  // Bytes anlegen die geschrieben werden sollen

4

5

    COPY_OF_FLASH_OBR = *(__IO uint32_t*)(0x4002201C);  // inhalt des optionbyte registers holen

6

    FLASH_OBR_MASK = 0xFC0003FF;  // maske damit nur die richtigen bytes verändert werden

7

    COPY_OF_FLASH_OBR &= FLASH_OBR_MASK; // nur die relevanten bytes werden gelöscht

8

    FLASH1 = 0x00;FLASH2 = 0x00;  // testweise sollen die beiden bytes den wert 0 haben

9

    COPY_OF_FLASH_OBR |= ( (uint32_t)(FLASH1<<10) | (uint32_t)(FLASH2<<18) );  // verändern des buffers

10

    *(__IO uint32_t*)(0x4002201C) = COPY_OF_FLASH_OBR;  // zurückschreiben

11

    COPY_OF_FLASH_OBR = *(__IO uint32_t*)(0x4002201C);  //erneutes auslesen des registers

A. K. schrieb:
> Jetzt verstehe ich deine Frage oben. Wenn man einfach mal rumprobiert
> ohne auch nur eine Zeile Doku zu lesen...

Zugegeben, dass das so nicht funktioniert war mir schon klar bevor ich 
es probiert habe. Ich wollte nur ein beispiel geben wie ich es mir vom 
prinzip her gerne gewünscht hätte. dass ich natürlich nicht einfach so 
auf den flash schreiben kann wusste ich schon.

Okay, ich muss zugeben, ich hab mich auch ein bischen in den APP-Notes 
verlaufen. Also ich lese jetzt nochmal das PM0075

Vielen dank für eure geduld :)

Eine Kleinigkeit zur Konvention von C Code: Wer Variablen konsequent 
gross schreibt, der riskiert süffige Kommentare vom Forum, sobald er bei 
etwaigen Fragen mal seinen Code rausrückt.

Üblich ist: Makros gross, Funktionen und Variablen klein oder mixed.

Auch sowas wie
  *(__IO uint32_t*)(0x4002201C)
macht sich an einer einzigen Stelle per #define besser, wenns nicht 
sowieso schon in einem Include des Entwicklungssystems drin steht.

A. K. schrieb:
> Eine Kleinigkeit zur Konvention von C Code: Wer Variablen konsequent
> gross schreibt, der riskiert süffige Kommentare vom Forum, sobald er bei
> etwaigen Fragen mal seinen Code rausrückt.
>
> Üblich ist: Makros gross, Funktionen und Variablen klein oder mixed.

Klingt vielleicht wie eine billige ausrede, aber ich hab das jetzt nur 
so gemacht dass ich es in meinem code erkenne :)

IchSchreibMeineVariablenNaemlichImmerSo :)