Wie sieht der Inhalt vom Flash bei einem fabrikneuen Controller von ST aus? Leider konnte ich im Datenblatt und Reference Manual dazu nichts finden. Mir ist klar wie der Flash in den STM32 Controllern funktioniert und aufgebaut ist, "leer" ist er, wenn das jeweilige Bit auf 1 steht. Aber wie sieht der ganze Flash aus, wenn der Controller fabrikneu ist? Ist garantiert, dass jedes einzelne Bit auf 1 steht? Gibts da irgendwo offizielle Infos von ST dazu?
Karl K. schrieb: > Aber wie sieht der ganze Flash aus, wenn der Controller fabrikneu ist? Normalerweise ziehen sich die Hersteller auf den Standpunkt zurück das von 0xFF,0xAA oder 0x88 alles drauf stehen kann was sie wollen. Also auch Testmuster. Also... Karl K. schrieb: > Ist garantiert, dass jedes einzelne Bit auf 1 steht? ...nein
Karl K. schrieb: > Wie sieht der Inhalt vom Flash bei einem fabrikneuen Controller von ST > aus? Leider konnte ich im Datenblatt und Reference Manual dazu nichts > finden. Nur interessehalber: wozu könnte das wichtig sein?
Werner schrieb: > Nur interessehalber: wozu könnte das wichtig sein? Um sich einen Mass-Erase vor dem Schreib-/Flashvorang zu sparen. Beim F407 z.B. dauert ein Mass-Erase rund 30 Sekunden. Und wenn ich mehrere hundert bis tausend Geräte habe, kommt da doch einiges an Zeit zusammen. Wenn aber nicht alle Bits auf 1 stehen, kann nicht richtig programmiert werden.
Ich würde da auf nichts vertrauen. Nur wenn ich das selber mache, kann ich davon ausgehen, dass da auch wirklich nichts drinnen steht. Aber jedes FW-Upload Programm löscht doch sowieso vorher???? Für mein H7 nehme ich dfu-util, und das macht alles automatisch. Da ist kein leer setzen notwendig.
Karl K. schrieb: > F407 z.B. dauert ein Mass-Erase rund 30 Sekunden Ich habe zwar noch nie einen STM32 in der Hand gehabt, aber das kann ich nicht glauben. Damit wären die nicht so erfolgreich geworden. Mass-Erase hast Du doch, damit es eben nicht so lange dauert. Das klingt eher nach Sector-Erase gepaart mit schlechtem Werkzeug. Bei dem Baustein, der hier vor mir liegt, dauert ein Mass-Erase von 2 MB FLASH jedenfalls nur einen Wimpernschlag. Alles andere hätte mich auch gewundert.
Mox schrieb: > Bei dem Baustein, der hier vor mir liegt, dauert ein Mass-Erase von 2 MB > FLASH jedenfalls nur einen Wimpernschlag. Alles andere hätte mich auch > gewundert. Die Verification dauert etwas länger... Da ist das Programm aber schon im "gesäuberten" Controller.
STK500-Besitzer schrieb: > Die Verification dauert etwas länger... > Da ist das Programm aber schon im "gesäuberten" Controller. Interessant. Aber warum dauert die Verification mit Mass-Erase 30 Sekunden länger als ohne Mass-Erase? Nie im Leben wäre ich darauf gekommen, dass bei ST mit Mass-Erase gemeint ist, das Programm auch gleich in den Controller zu übertragen, inklusive Verifikation. Bislang dachte ich bei "Erase" immer nur an "Löschen". So kann man sich täuschen.
Karl K. schrieb: > Wenn aber nicht alle Bits auf 1 stehen, kann nicht richtig programmiert > werden. Warum sollte das bitte nicht gehen. Beim Programmieren wird sowieso je nach Einstellung der ganze flash gelöscht oder die Teile die neu geschrieben werden. Letzteres reicht vollkommen aus. Davon unabhängig ist mir bisher noch kein STM untergekommen der bei Auslieferung nicht voll mit 0xFF beschrieben war. Und das waren schon einige aus so ziemlich jeder Serie.
Ich habe grade mal getestet, bei meinem F7 Nucleo was ich hier grade rumliegen habe dauert der Full Chip Erase für die 2MB keine 8 Sekunden. Das der F4 so viel langsamer sein soll kann ich mir beim besten Willen nicht vorstellen.
Jan-Thomas schrieb: > Karl K. schrieb: >> Beim F407 z.B. dauert ein Mass-Erase rund 30 Sekunden. > > Wohl kaum. Mein Reden. :-)
Angehängte Dateien:
-
STM32F407-mass-erase.png
19 KB
Karl K. schrieb: > Mir ist klar wie der Flash in den STM32 Controllern funktioniert und > aufgebaut ist, "leer" ist er, wenn das jeweilige Bit auf 1 steht. Nicht einmal darauf kannst du dich verlassen. Bei manchen Chips sind die Bits nach dem Erase auf 0. Mindestens beim STM32L031 ist es so (RM0377, 3.3.4, Program a single word to Flash program memory). Und der STM32F407 darf offiziell für ein Mass Erase 32 Sekunden brauchen (bei 1.8V; bei 3.3V immer noch 16s).
Mox schrieb: > Interessant. Aber warum dauert die Verification mit Mass-Erase 30 > Sekunden länger als ohne Mass-Erase? > > Nie im Leben wäre ich darauf gekommen, dass bei ST mit Mass-Erase > gemeint ist, das Programm auch gleich in den Controller zu übertragen, > inklusive Verifikation. Bislang dachte ich bei "Erase" immer nur an > "Löschen". So kann man sich täuschen. Ich bezog mich auf die Löschdauer im Allgemeinen, wenn man das "richtige" Werkzeug verwendet. ST bietet das STM32 ST-Link Utilitiy an. Damit solltest du deine "These" mal überprüfen.
Spricht was dagegen, einfach vor dem Löschen zu lesen ob alles 0xFF ist, und nur bei Bedarf zu löschen? Außerdem nutzt der Bootloader den Flashinhalt um sich beim ersten Start bei Bedarf zu aktivieren: file:///home/maltem/Downloads/cd00167594-stm32-microcontroller-system-me mory-boot-mode-stmicroelectronics.pdf Das sollte zumindest bei der Auslieferung für einen standartisiertern Inhalt für jeden Typ sprechen.
Jan-Thomas schrieb: > Wohl kaum. Klar, ausprobiert mit ST-Link Utility. Sind vielleicht nicht genau 30 Sekunden, können auch 20 oder 25 sein, aber es dauert. (Full Chip Erase Button in ST-Link Utility). Zum Vergleich beim L431 dauerts keine Sekunde bis es erledigt ist. Malte schrieb: > Spricht was dagegen, einfach vor dem Löschen zu lesen ob alles 0xFF ist, > und nur bei Bedarf zu löschen? Nein, spricht nichts dagegen.
Man könnte ja auch mal das Datenblatt zu Rate ziehen, bevor man so einen Sturm im Wasserglas entfacht ... "5.3.12 Memory characteristics Flash memory ... The devices are shipped to customers with the Flash memory erased."
Angehängte Dateien:
-
f407_erase.png
92 KB -
l431_erase.png
120 KB
Siehe Bilder anbei, Screenshots aus den aktuellen Datenblättern. F407 braucht für einen Mass Erase wirklich mehrere Sekunden.
A. B. schrieb: > The devices are shipped to customers with the Flash memory erased. Vielen Dank! Die Zeile muss ich wohl überlesen haben.
Malte schrieb: > Spricht was dagegen, einfach vor dem Löschen zu lesen ob alles 0xFF ist, > und nur bei Bedarf zu löschen? Damals 1860 in den Ardennen haben wir das noch so gemacht. Nannte sich "Blankcheck". Der EPROMmer hat geguckt ob der Chip leer ist. Falls nicht hat er geguckt ob das neue Bitmuster über das alte passen würde (verboten aber funktioniert). Und wenn beide Tests negativ waren, musste gelöscht werden. 32 Sekunden löschen, Luxusprobleme :-)
Karl K. schrieb: > Werner schrieb: >> Nur interessehalber: wozu könnte das wichtig sein? > > Um sich einen Mass-Erase vor dem Schreib-/Flashvorang zu sparen. Beim > F407 z.B. dauert ein Mass-Erase rund 30 Sekunden. Und wenn ich mehrere > hundert bis tausend Geräte habe, kommt da doch einiges an Zeit zusammen. > Wenn aber nicht alle Bits auf 1 stehen, kann nicht richtig programmiert > werden. BWL-er? Wie lange hast Du gebraucht, um Dir das alles auszudenken und zu recherchieren? Welchem geldwerten Vorteil einspricht das? Wie willst Du diese Summe, umgerechnet in eingesparte Testzeit, jehmals wieder "rein holen"?
STK500-Besitzer schrieb: > Ich bezog mich auf die Löschdauer im Allgemeinen, wenn man das > "richtige" Werkzeug verwendet. > ST bietet das STM32 ST-Link Utilitiy an. Damit solltest du deine "These" > mal überprüfen. Ich habe mit dem JLink leider nur das "falsche" Werkzeug und auch keinen STM32, ich kann das also nicht prüfen, daher kam doch die Frage. Der JLink erledigt das Löschen auf meinen Bausteinen jedenfalls in deutlich unter einer Sekunde, auch wenn der µC zuvor nicht leer war. Aber sei´s drum, wenn das für die STM32 normal ist, dann ist´s ja gut. Ich hatte mich nur gewundert.
Mox schrieb: > JLink erledigt das Löschen auf meinen Bausteinen jedenfalls in deutlich > unter einer Sekunde, auch wenn der µC zuvor nicht leer war. > > Aber sei´s drum, wenn das für die STM32 normal ist, dann ist´s ja gut. > Ich hatte mich nur gewundert. Der löscht auch nur slektiv die Sektoren, die er auch umprogrammieren muss. Wenn der JLINk den vollen Flash löscht, dauert das auch seine Zeit. Generell ist der Flash / NVM bei den meisten Chips im Auslieferzustand auf "geladen". In der Regel sind die bits dann auf 1. Diesen Zustand benötigt man für die Margin-Tests, mit denen die Speicherzellen geprüft werden. Leider geben die meisten Hersteller ihre NVM Controller nicht im Datenblatt frei. Sonst könnte man als Enduser auch einen Test machen, ob die Speicherzellen noch in Ordnung sind und Ladung halten :(.
Karl K. schrieb: > Siehe Bilder anbei, Screenshots aus den aktuellen Datenblättern. > F407 > braucht für einen Mass Erase wirklich mehrere Sekunden. Bei der Fusitsu FMC² Reihe konnte man sich auch erschrecken. In der Regel dauerte ein Löschvorgang unter 1 Sekunde. Es konnte aber je nach Zustand (wieviele Bits auf 0, Alter, Anzahl Löschvorgänge) durchaus auf >10 Sekunden gehen. Ungläubiger Blick ins Datenblatt offerierte dann ebenfalls Zeiträume bis zu 30sec max.
Warum sollte der Flash eigentlich komplett gelöscht werden? Ist das als irgendeine Art von Mitigation gegen marodierende Program Counter gedacht? (Man verzeihe mir das Denglisch - ich kenne die deutschen Begriffe nicht.)
:
Bearbeitet durch User
Walter T. schrieb: > Mitigation gegen marodierende Program Counter > ich kenne die deutschen Begriffe nicht Dass heißt: Work-Around gegen amok laufende Pointer :-)
Walter T. schrieb: > Warum sollte der Flash eigentlich komplett gelöscht werden? Um eine saubere Programmierung zu gewährleisten, durch das Löschen stellt man sicher, das die Zellen korrekt gelöscht sind und der Ladungszustand nicht kurz vor dem kippen ist. Es gibt tatsächlich sogar Controller, bei denen es möglich ist den Ladungszustand der Speicherzellen zu messen (Stichwort: Cell Margin Verification).
Marc X. schrieb: > Walter T. schrieb: >> Warum sollte der Flash eigentlich komplett gelöscht werden? > > Um eine saubere Programmierung zu gewährleisten, durch das Löschen > stellt man sicher, das die Zellen korrekt gelöscht sind Verstehe ich nicht. Dazu ist es doch ausreichend, die Sektoren komplett zu löschen, die später auch benutzt werden.
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.