Hallo Leute, ich habe folgendes Problem. Ich habe eine Software die auf verschiedenen Hardwares läuft.(Alles mit den gleichen STM32F103RET6-controllern). Je nachdem auf welcher Hardware sich die Software befindet soll sie entsprechendes Verhalten an den Tag legen. Dazu habe ich 2 prinzipielle Lösungsansätze: 1. Ich verdrahte einige Pins des µC auf High und Low und habe somit eine Hardwarecodierung die ich am Programmstart auslese. 2. Ich benutze einen Nichtflüchtigen Speicher, den ich 1 mal beschreibe. Dazu könnte man wunderbar einen EEPROM hernehmen. Jetzt ist meine Frage: Kennt jemand eine bessere Möglichkeit als einen externen EEPROM zu nehmen? Zur not könnte man was in den Flashspeicher schreiben. Aber ich hätte lieber eine Lösung, die nach dem Flashen immernoch funktioniert. Wenn jemand einen guten Rat oder auch einfach nur eine Idee hat wäre ich wirklich dankbar. ein paar schlagworte würden es zur not auch tun :) Vielen dank Tarkan
Was ich noch vergessen habe: Mir würden schon wenige Bytes( < 10 ) reichen.
Gast
#2450204
Hast du dir schon die AN2594 angesehen? http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00165693.pdf
Gast
#2450205
ST hat eine Applikationsschrift zum Benutzen des Flash als EEPROM Ersatz. Bei Preisen von 0.40 Euro wuere ich aber ein externes I2C EEPROM vorsehen...
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".
Gast
#2450292
ich nütze für solche Dinge immer einen Bereich im µC-eigenen Flash. Es ist ja nicht so dass beim Flashen immer alles gelöscht werden muss! Im Flashprogramm gibt es meist einen Haken "retain unchanged main memory" / "no Full erase" / "erase sectros"....
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.
Angehängte Dateien:
-
Bild1.png
(42 KB)
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
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 :)