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.
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."
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.)
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.
