Hallo, ich habe nun seit einiger Zeit ein STM32F407 DISCOVERY board. Bisher bin verschiedene Dinge am Ausprobieren und ständig am flashen. Im Datenblatt des Chips steht aber, dass dieser nur 10000 Schreibzyklen verträgt. Wie gesagt, habe ich mir bisher darüber keine Gedanken gemacht, weil ich bisher dachte, dass diese Chips 100000 Schreibzyklen abkönnen. Meine Frage ist jetzt eigentlich, wie ich richtig mit diesen Chips umgehe? Ich bin nach wie vor nur am herum experimentieren, ohne konkretes Ziel. Gibt es eine Möglichkeit bevor man Programme "flasht" diese zu simulieren? Oder kann man diese vorher debuggen, bevor man sie brennt? Wie machen das die Profis? Gruß Kai
Die 10000 ist die garantierte Mindestanzahl an Schreibzyklen, die tatsächlich mögliche Anzahl kann deutlich höher liegen - dafür legt der Hersteller aber nicht die Hand ins Feuer. Diese Anzahl ist aber nicht so wenig wie man glaubt. Wenn man den Chip täglich 100mal programmiert, sind das mindestens 100 Tage intensiver Arbeit mit dem Chip. Brennt er irgendwann durch, muß man ihn halt auswechseln. Gruß. Tom
Wahrscheinlich werde ich dann wohl nicht so schnell an die Grenzen des Chips stoßen. Aber kann man denn so ohne weiteres als Hobbybastler den Chip auslöten bei den Discovery boards? Da braucht man doch sicherlich ein spezielles Lötgerät.
Den defekten Chip mit Heißluft vorsichtig auslöten ist kein Problem, er ist ja schon hinüber. Sonst mit einem Cuttermesser oder Skalpell die Beinchen vorsichtig abschneiden, damit die Lötpads nicht beschädigt werden und anschließend die Reste einzeln mit dem Lötkolben entfernen. Die Pads mit Entlötlitze von Lötzinnresten befreien und schon ist die Platine bereit für einen neuen Chip. :-)
Wieso ist das technisch eigentlich so? Wieso lässt sich der Chip nicht beliebig oft beschreiben? Was geht denn da auf Dauer kaputt?
Der STM32 kann auch Code aus dem RAM ausführen. Richtiges Compilieren & Linken vorausgesetzt, kannst du über JTAG/SWD den Code in den RAM schreiben und von da starten. So spart man sich Flash-Zyklen
Kai Wierzoch schrieb: > Wie machen das die Profis? Wenn dein Programm in den RAM passt, kannst du es auch direkt dort ausführen ohne den Flash zu bemühen. Hier eines von vielen Beispielen für die Anpassung des Linker-Scripts: http://libopencm3.org/wiki/Run_From_RAM
Kai Wierzoch schrieb: > Aber kann man denn so ohne weiteres als Hobbybastler den Chip auslöten > bei den Discovery boards? Der STM32 Chip einzeln kostet in etwa soviel wie das ganze Discovery Board. Da lohnt sich das auslöten nicht besonders...
> Wieso lässt sich der Chip nicht beliebig oft beschreiben?
Das würde mich auch mal interessieren. Klar ist, dass die Speicherzellen
verschließen, aber warum das so ist, konnte ich nicht herausfinden.
Da wird wohl auf dem Floating Gtae eine Hand voll Elektronen abgelegt
oder wieder entfernt. Warum zerstört dieser Vorgang den Transistor
(langfristig)?
Stefanus schrieb: > a wird wohl auf dem Floating Gtae eine Hand voll Elektronen abgelegt > oder wieder entfernt. Warum zerstört dieser Vorgang den Transistor Weil dazu Überspannung an das Gate angelegt wird, die "fast" einen Durchschlag durch das Gate erzeugt.
Uwe Bonnes schrieb: > Stefanus schrieb: >> a wird wohl auf dem Floating Gtae eine Hand voll Elektronen abgelegt >> oder wieder entfernt. Warum zerstört dieser Vorgang den Transistor > > Weil dazu Überspannung an das Gate angelegt wird, die "fast" einen > Durchschlag durch das Gate erzeugt. Weil Elektronen auch an Plätze wandern wo man sie nicht mehr weg bekommt. Dadurch verschiebt sich auch die Schwellspannung. Irgendwann hat man dann keinen vernünftigen Arbeitsbereich mehr. Sei froh, dass wenigstens 10000 mal programmieren garantiert wird. Bei den Solid State Disks(SSD) ist gerade mal noch 1000 mal beschreiben möglich.
:
Bearbeitet durch User
Die Anzahl Flashzyklen kann dann eine sehr reale Rolle spielen, wenn man Debugging mit Breakpoints macht, und diese nicht in der Debug-Engine des Chips sondern durch um-flashen vom Code realisiert werden.
Helmut S. schrieb: > Sei froh, dass wenigstens 10000 mal programmieren garantiert wird. Bei > den Solid State Disks(SSD) ist gerade mal noch 1000 mal beschreiben > möglich. Schon mal einen µC mit wear levelling gesehen?
Werfe bei jedem Brennvorgang einfach einen cent in eine Spardose. Wenn das Ding dann kaputt geht, hast Du mindestens. 100 Euro zusammen und kannst Dir damit fast 10 neue Boards kaufen... Soll heißen: Mache Dir über die Anzahl der möglichen Brennzyklen keine Gedanken. Bevor Du die erreichst, wirst Du das Board wohl eher beim Experimentieren auf andere Art und Weise kaputt machen. ;)
A. K. schrieb: > und diese nicht in der Debug-Engine des > Chips sondern durch um-flashen vom Code realisiert werden. Kommt das in der freien Wildbahn vor? Sowas habe ich bis jetzt nur ab RAM gesehen. Da die STM32 aber, soweit ich mich erinnere, acht HW-Breakpoints unterstützen, ist das ja zum Glück kein Thema. A. K. schrieb: > Schon mal einen µC mit wear levelling gesehen? (ich weiss, das ist was völlig anderes, kam mir nur gerade in den Sinn) ST Micro bietet einen "EEPROM-Emulator" zum Download an. der macht einfaches Wear Leveling. Ist praktisch, wenn man Parameter speichern will, und so doch irgendwann mal 10'000 Zyklen ein bisschen knapp werden. Kai Wierzoch schrieb: > Was ist denn wear leveling? Vereinfacht gesagt: Wenn Du etwas speicherst, schaut ein Wear Leveling Algo zu, dass Du das nicht immer in die gleichen Zellen schreibst. Beispiel USB-Stick: Wenn Du da eine Datei überschreibst, überschreibst Du die Daten nicht, sondern legst sie in einem unbenutzten Bereich neu ab. So, dass - wie der Name eben sagt - der Verschleiss der echten Speicherzellen gleichmässig verteilt ist. Ausführlicheres weiss sicher Wikipedia.
Kai Wierzoch schrieb: > A. K. schrieb: >> >> Schon mal einen µC mit wear levelling gesehen? > > Was ist denn wear leveling? Man benutzt laufend andere Speicherbereiche um zu vermeiden immer die gleichen Zellen zu löschen und beschreiben. Bei deinem ARM Prozessor müsstest du jedes Mal den Speicheranfang des Programms und der konstanten Daten auf den nächst höheren Adressbereich(nächst höheren Sektor) legen anstatt immer die gleiche Basis-Adresse zu nehmen.
:
Bearbeitet durch User
Dirk schrieb: > Wenn dein Programm in den RAM passt, kannst du es auch direkt dort > ausführen ohne den Flash zu bemühen. Hier eines von vielen Beispielen > für die Anpassung des Linker-Scripts: > > http://libopencm3.org/wiki/Run_From_RAM Ich setze die CooCox IDE ein. Wie funktioniert das denn da? Wo ist denn das Linkerscript, in dem ich das ändern kann. Kai Gruß
kai schrieb: > Ich setze die CooCox IDE ein. Wie funktioniert das denn da? Project Configuration -> Link -> Debug from Ram anklicken.
Das habe ich schon ausprobiert. Wenn ich dann Debug drücke führt er das Programm auch aus. Wenn ich dann Änderungen am Quellcode gemacht habe und wieder Debug drücke, führt er das Programm aus, allerdimgs die Version vor der Änderung. Mache ich was falsch? Compiliert habe ich vorher.
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.