Hallo liebe Community,
ich habe etwas beobachtet und würde gerne verstehen wie dies möglich
ist.
In einem stm32f302cb mit 128K habe ich ein Programm, das größer als 128K
ist, geladen. Erstens hat es mich gewundert, dass ich es überhaupt
hineinladen konnte und mir ein "successfull" gemeldet wurde. Weiterhin
wundert mich, dass dieses Programm bisher einwandfrei läuft...
Ich habe sowohl das Mapping file, als auch die Hex datei kontrolliert
und festgestellt, dass das Programm die 128K übersteigt. Mit ST-Link
Utility habe ich mich mit dem Controller verbunden und dort die Size von
128K ausgelsen. Weiterhin habe ich mir den Inhalt des Flash angeschaut
und auch dort festgestellt, das die Daten jenseits der 128K korrekt sind
(mit Hex-File verglichen).
So nun meine Frage. Wie ist das möglich?
stm32 schrieb:> Ich habe sowohl das Mapping file, als auch die Hex datei kontrolliert> und festgestellt, dass das Programm die 128K übersteigt.
Wie genau hast Du die Programmgröße ermittelt?
Die Dateigröße des .hex files ist übrigens ~2,5x größer.
stm32 schrieb:> So nun meine Frage. Wie ist das möglich?
Dein Programm darf nun einfach nicht die Funktionen verwenden, die nicht
mehr ins Flash gepasst haben. Dann merkst du das niemals.
Wenn du z.B. einen dicken Kratzer auf der DVD hast, dann kannst du ja
auch problemlos den Film bis dahin anschauen... ;-)
> Wie ist das möglich?
Normalerweise gar nicht, weil schon das Verifizieren beim Programmieren
schief geht.
Das geht nur dann, wenn der Controller tatsächlich mehr als 128kB Flash
hätte. Wenn du tatsächlich nachweislich Speicher oberhalb der 128kB
schreiben und lesen kannst, wird das wohl der Fall sein. Warum auch
immer.
Das "nachweislich" solltest du aber wirklich nachweislich sichergestellt
haben ;)
Oliver
Das ist bei vielen STM32 Controllern so. Anscheinend werden immer
dieselben Dies in den Controllern eingesetzt und erst durch
Programmieren des FLASH_SIZE-Registers die Größe bestimmt. Ich hatte das
erst letztens bei einem STM32F030K6, der laut Datenblatt und
FLASH_SIZE-Register eigentlich nur 32k Flash besitzt. Ich konnte
problemlos den Speicher bis 64k schreiben und lesen. Ich weiss nicht
mehr genau, welcher STM32-Controller das war, aber der Extremfall war,
dass nur 64k im Datenblatt und Register angegeben, aber 512k vorhanden
waren. Der Speicher war auch völlig in Ordnung, ich habe Schreib- und
Lesetests mit verschiedenen Pattern auf den "nicht vorhandenen" Speicher
gemacht, alles in Ordnung.
Man sollte sich jedoch nicht darauf verlassen, dass dieser Speicher
immer vorhanden ist, vor allem, wenn man die Controller in Seriengeräten
einsetzt. Es kann gut möglich sein, dass bei einer neuen Charge dieser
Speicher nicht mehr vorhanden ist.
Stefan P. schrieb:> Wie genau hast Du die Programmgröße ermittelt?> Die Dateigröße des .hex files ist übrigens ~2,5x größer.
Ich habe doch nicht die Dateigröße des Hexfiles gemeint. Wenn ich das
Hexfile mit dem Editor öffne, kann ich ja auslesen von welcher Adresse
bis zu welcher Adresse mein Programm steht. Das hat der Compiler ja
generiert.
Gleichzeitig habe ich im Map File überprüft wo die Endadresse meines
Programms steht.
Anfangsadresse: 0x08000000
Endadresse: 0x080307C0
Deutlich jenseits der 128K (Endadresse 0x0801FFFF)
Lothar M. schrieb:> Dein Programm darf nun einfach nicht die Funktionen verwenden, die nicht> mehr ins Flash gepasst haben. Dann merkst du das niemals.
Genau das habe ich auch überprüft. Im Map file stehen die
Einsprungadressen meiner Funktionen ja im Klartext. Diese Funktionen
habe ich gezielt getestet und auch plausible Rückantworten bekommen.
> 0x080307C0
Das koennte auch die Adresse des Optionbytes sein.
Das ST-Link Utility glaubt im uebrigen streng an die Typenbezeichnung.
Und der unter/beigeordnet ist die Flashgroesse.
Das die auch nochmal extra per Register auslesbar ist,
interessiert das ST-Link Utility nicht im geringsten...
STM32-Experte schrieb im Beitrag #5563147:
> Das ist bei vielen STM32 Controllern so. Anscheinend werden immer> dieselben Dies in den Controllern eingesetzt und erst durch> Programmieren des FLASH_SIZE-Registers die Größe bestimmt. Ich hatte das> erst letztens bei einem STM32F030K6, der laut Datenblatt und> FLASH_SIZE-Register eigentlich nur 32k Flash besitzt. Ich konnte> problemlos den Speicher bis 64k schreiben und lesen. Ich weiss nicht> mehr genau, welcher STM32-Controller das war, aber der Extremfall war,> dass nur 64k im Datenblatt und Register angegeben, aber 512k vorhanden> waren. Der Speicher war auch völlig in Ordnung, ich habe Schreib- und> Lesetests mit verschiedenen Pattern auf den "nicht vorhandenen" Speicher> gemacht, alles in Ordnung.> Man sollte sich jedoch nicht darauf verlassen, dass dieser Speicher> immer vorhanden ist, vor allem, wenn man die Controller in Seriengeräten> einsetzt. Es kann gut möglich sein, dass bei einer neuen Charge dieser> Speicher nicht mehr vorhanden ist.
Das finde ich sehr interessant. Dann ist es wohl gar nicht so
außergewöhnlich, wie es mir zuerst erschien. Danke für dein Feedback.
Das betrifft übrigens nicht nur die Flashgröße, sondern auch
Peripherieteile wie Timer, USB,...:
Die kleinen STM32F030F4 verwenden wohl den gleichen Die wie die
STM32F031F6. Man kann also auf einem STM32F030F4 nicht nur 32kB Flash,
sondern auch problemlos den TIM2 verwenden, der eigentlich lt.
Datenblatt dort gar nicht vorhanden ist und erst im STM32F031 mit drin
ist.
Genauso ist es mit dem USB bei den STM32F101C: das sind die selben Dies
wie die STM32F103C, man kann die also auch mit 72MHz betreiben und die
USB-Peripherie verwenden.
Ein guter Indikator welche Dies identisch sind, sind die Bootloader-IDs
in der AN2606.
Gerd E. schrieb:> Das betrifft übrigens nicht nur die Flashgröße, sondern auch> Peripherieteile wie Timer, USB,...:
Man sollte sich allerdings nicht darauf verlassen, daß die
"Gratiszugabe" auch 100% funktioniert. Beim Hersteller sind sie eher
nicht getestet worden oder schlimmer: Höherwertige Typen mit z.B.
teilweise defektem Speicher werden zu "low cost" Typen deklariert und
verkauft um den Ausschuß zu minimieren. Kennt man ja auch von CPUs und
Graphikkarten für PCs.
Wie ja bereits schon mehrfach erwähnt, ist die Flash-Größe meistens mehr
als angegeben. ST garantiert aber nur, dass die angegeben Größe
funktioniert, alles dahinter ist Glücksspiel und maximal für private
Basteleien geeignet.
Aber ich glaube nicht, dass dein Programm größer ist.
1. Schreibt ST-Link nur so viel, wie der Controller angibt zu besitzen.
Um mehr zu schreiben, muss man ST-Link dazu zwingen (durch einen extra
Parameter)
2. Wenn dein Programm größer ist, als im Linker File angegeben, wird der
Compiler/Linker garantiert einen Fehler schmeißen.
mfg
Ingenieur schrieb:> Höherwertige Typen mit z.B.> teilweise defektem Speicher werden zu "low cost" Typen deklariert und> verkauft um den Ausschuß zu minimieren.
Bei den Preisen von Mikrocontrollern dürfte es billiger sein, Wafer oder
ungetestete Chips auf Halde zu legen, bei Bedarf an Subtyp XYZ genau und
nur das dafür nötige Profil zu testen und ggf ganz zu verwerfen.
Die Kosten für den Test werden einen signifikanten Teil der
Herstellungskosten ausmachen und ein grosses Testprofil ist
rausgeworfenes Geld, wenn du nur einen kleinen brauchst. Zudem ist die
Logistik billiger, wenn hinten nur 2 Möglichkeiten rauskommen, OK oder
Schrott, statt 20 Subtypen.
> Kennt man ja auch von CPUs und Graphikkarten für PCs.
Die sind allerdings auch ein paar Cent teurer und arbeiten an der Grenze
der Performance der eingesetzten Herstellungstechnik. Mikrocontroller
sind deutlich genug von der Grenze entfernt, um hinsichtlich Performance
kaum Ausbeuteprobleme zu haben.
Felix F. schrieb:> Aber ich glaube nicht, dass dein Programm größer ist.> 1. Schreibt ST-Link nur so viel, wie der Controller angibt zu besitzen.> Um mehr zu schreiben, muss man ST-Link dazu zwingen (durch einen extra> Parameter)> 2. Wenn dein Programm größer ist, als im Linker File angegeben, wird der> Compiler/Linker garantiert einen Fehler schmeißen.
Dann glaubst du mir eben nicht...
Mein Projekt ist auf den stm32f302cc (also 256K) Chip aufgesetzt. Wie
ich dazu gekommen bin dieses Programm auf einen 128K Chip zu spielen?
Ich habe meinen CAN Bootloader getestet. Dabei teste ich auch mögliche
Szenarien, die zu Fehlern führen könnten, um diese möglichst zu
eliminieren. Ein Szenario war, eine neue FW größer 128K auf eine alte
Hardware mit 128K Chip zu spielen. Beim anschließenden Lesen des
Speicherinhalts staunte ich nicht schlecht, als mir gemeldet wurde, dass
alle Bereiche in Ordnung sind.
Und da wollte ich es genauer wissen und habe mal hier nachgefragt. Oft
ist man nicht der Erste, der auf etwas "Neues" gestoßen ist.
stm32 schrieb:> Mein Projekt ist auf den stm32f302cc (also 256K) Chip aufgesetzt.
Das hast du nirgendwo erwähnt. Dann ist natürlich klar, das der Compiler
keinen Fehler wirft.
stm32 schrieb:> Ich habe meinen CAN Bootloader getestet.
Dass du einen eigenen Bootloader verwendest, der anscheinend ohne
Speicherüberprüfung schreibt, was du im vorgibst, hast du auch nicht
erwähnt.
Dann ist es natürlich möglich.
mfg
stm32 schrieb:> Felix F. schrieb:>> Aber ich glaube nicht, dass dein Programm größer ist.>> 1. Schreibt ST-Link nur so viel, wie der Controller angibt zu besitzen.>> Um mehr zu schreiben, muss man ST-Link dazu zwingen (durch einen extra>> Parameter)>> 2. Wenn dein Programm größer ist, als im Linker File angegeben, wird der>> Compiler/Linker garantiert einen Fehler schmeißen.>> Mein Projekt ist auf den stm32f302cc (also 256K) Chip aufgesetzt.
Aha. Schön daß du das auch mal sagst.
> Ich habe meinen CAN Bootloader getestet. Dabei teste ich auch mögliche> Szenarien, die zu Fehlern führen könnten, um diese möglichst zu> eliminieren. Ein Szenario war, eine neue FW größer 128K auf eine alte> Hardware mit 128K Chip zu spielen.
Aha. Schön daß du das auch mal sagst. Auf den gebräuchlichen Wegen, den
Flash zu beschreiben (das betrifft den Werks-Bootloader genauso wie SWD
oder JTAG) geht das nämlich nicht. Zumindest nicht ohne Tricks.
> Beim anschließenden Lesen des> Speicherinhalts staunte ich nicht schlecht, als mir gemeldet wurde,> dass alle Bereiche in Ordnung sind.
Dein Bootloader ist karpott, wenn er mehr Flash beschreibt, als das
FLASH_SIZE Register hergibt.
Felix F. schrieb:> Das hast du nirgendwo erwähnt. Dann ist natürlich klar, das der Compiler> keinen Fehler wirft.
Ist meiner Meinung nach nicht für meine Fragestellung relevant gewesen.
Ich habe ja ausdrücklich erwähnt, dass mein Programm größer als 128K
ist.
Axel S. schrieb:> Auf den gebräuchlichen Wegen, den> Flash zu beschreiben (das betrifft den Werks-Bootloader genauso wie SWD> oder JTAG) geht das nämlich nicht. Zumindest nicht ohne Tricks.
Da muss ich dir widersprechen. Ich habe das Programm ganz einfach mit
KEIL über JTAG auf meinen Controller gespielt. Dazu waren keine Tricks
nötig.
Projekt öffnen -> Hardware mit JTAG verbinden -> Flashen
Es gab keinerlei Warnungen seitens KEIL.
ST-Link und die ST-Link-Software zeigt die Speichergröße des Controllers
zwar an, man kann aber getrost auch über diese Grenze hinaus Lesen und
Schreiben. Klappt einwandfrei. Mehrfach getestet.
STM32-Experte schrieb im Beitrag #5563554:
> ST-Link und die ST-Link-Software zeigt die Speichergröße des> Controllers> zwar an, man kann aber getrost auch über diese Grenze hinaus Lesen und> Schreiben. Klappt einwandfrei. Mehrfach getestet.
Kommt dann ab einer bestimmten Größe mal ein Fehler?
Bauform B. schrieb:> Ich hab' die mal nach DIE sortiert
Schöne Liste hast du da gemacht ;)
Ich hatte das mit dem Die-Tag auch irgendwann mal entdeckt aber wollte
es nicht an die große Glocke hängen, weil ich es ehrlich gesagt ziemlich
nett von ST finde, wie offen sie mit den Daten umgehen und nicht alles
hinter irgendeinem Cloud-Müll verstecken ;)
Es gibt 47 verschiedene Dice:
1
for file in STM32*.xml; do cat $file | grep "<Die>"; done | awk '!seen[$0]++' | wc -l
2
47
und 1207 verschiedene Controller (zzgl. unterschiedliche
Temperaturbereiche):
1
for file in STM32*.xml; do cat $file | grep "<Flash>" ; done | wc -l
2
1207
Das ist immerhin ~25x soviel. Die meisten Varianten kommen aber auch
schlicht und einfach durch unterschiedliche Gehäuse oder allgemein
unterschiedliches Bonding (in der Fxx8-Serie mit 1.8V wird der LDO mWn
einfach "übergangen").
Was die Lauffähigkeit der Peripherie und des Flash angeht, so wird man
natürlich keine verlässlichen Aussagen bekommen aber ich vermute mal,
dass ST per Die testet und nicht per Variante. Das hat meiner Meinung
nach den Vorteil, dass man weniger verschiedene Tests hat und das spart
vermutlich am Ende mehr Zeit, Geld und Nerven, als wenn man mal hier
einen Timer oder da mal 64kB Flash beim Test auslässt.
Christopher J. schrieb:> Was die Lauffähigkeit der Peripherie und des Flash angeht, so wird man> natürlich keine verlässlichen Aussagen bekommen aber ich vermute mal,> dass ST per Die testet und nicht per Variante. Das hat meiner Meinung
Testzeit kosten. Und z.B. den Flash zu testen kostet Zeit!
Uwe B. schrieb:> Und z.B. den Flash zu testen kostet Zeit!
Und was willst du uns damit sagen?
Das ST die Chips ungetestet verkauft?
Ist es billiger, alle Dies mit dem gleichen Testverfahren und der
gleichen Testzeit zu bearbeiten, oder ist es billiger, 4 verschiedene
geringfügig schnellere, unterschiedlich lange Testvarianten zu fahren?
Ich denke, dass nur das getestet was für die beabsichtigte Variante
gebraucht wird. Und ich denke nicht, dass versucht wird dabei
durchgefallenen Exemplare in kleineren Controllern doch noch an den Mann
zu bringen.
Aber vielleicht WEISS jemand was genaues. Vermuten kann man viel.
H.Joachim S. schrieb:> Aber vielleicht WEISS jemand was genaues. Vermuten kann man viel.
Wissen wird das wohl nur ST selber. Wer weiß ob sie überhaupt alles
testen.
Mindestens die Eigenschaften, die im Datenblatt als Min/Max Werte
zugesagt sind, wird jeder vernuenftige Hersteller testen.
Falls die Ausbeute einigermassen hoch ist, was ich fuer die 130 und 90
nm STM32 annehme, macht es wenig Sinn, die wenigen Exemplare des
STM32F103x[8|B] Chips, die als 103xB getestet wurden und nur im
Flashbereich ueber 64 Ki ausfallen sind, extra zu handhaben und als
103x8 zu sortieren. Der Handhabungsaufwand wird ein Vielfaches groesser
sein als die Ersparniss.
Wenn nur die obere Hälfte des Flash Speicher mangelhaft ist, kann man
den Chip noch gut als 64kB Version verkaufen. Zum Wegschmeißen wäre er
zu schade.
Was glaubt ihr denn, warum die Chinesen diese Chips für ca. 90 Cent an
Endkunden verkaufen können, obwohl sie bei jedem europäischen
Großhändler selbst in 10.000er Paketen teurer sind? Das ist schlicht und
ergreifend B-Ware.
Da gibt es noch ein ähnliches Thema: Ich habe zahlreiche
Programmieradapter mit STM32F101 vorliegen. Diese Chip dürften
eigentlich nur mit 36MHz getaktet werden und keinen USB Anschluss haben.
Tatsächlich werden sie aber mit 72MHz getaktet und haben einen USB
Anschluss. Tatsächlich ist dort eine Firmware drauf, die für STM32F103
gedacht war.
Auch hier verwursten die Chinesen umgelabelte B-Ware, um Produkte zu
einem günstigen Preis anbieten zu können.
Stefanus F. schrieb:> Wenn nur die obere Hälfte des Flash Speicher mangelhaft ist, kann man> den Chip noch gut als 64kB Version verkaufen.
Bei passender Berücksichtigung im Design kann man das auch machen, wenn
die untere Hälfte des Speichers mangelhaft ist, indem man die oberste
Adressleitung auf Vcc zieht.
ST wird das aber eher nicht machen. :-)
Stefanus F. schrieb:> Da gibt es noch ein ähnliches Thema: Ich habe zahlreiche> Programmieradapter mit STM32F101 vorliegen. Diese Chip dürften> eigentlich nur mit 36MHz getaktet werden und keinen USB Anschluss haben.
Wie schon oben beschrieben sind alle STM32F10xX[8|B] der gleiche Chips.
Stefanus F. schrieb:> Was glaubt ihr denn, warum die Chinesen diese Chips für ca. 90 Cent an> Endkunden verkaufen können, obwohl sie bei jedem europäischen> Großhändler selbst in 10.000er Paketen teurer sind?
Weil der Markt in China anders funktioniert. Da gibt es Großkunden, die
die Dinger nicht in 10.000er Paketen kaufen, sondern noch in deutlich
größeren Mengen. Die bekommen dann entsprechende Rabatte. Und außerdem
sind die sich nicht zu schade noch ein kleines Zubrot zu verdienen,
indem sie ein paar mehr kaufen, die sie dann an kleinere Chiphändler
weiterverkaufen. Die verkaufen die dann über Taobao, Aliexpress etc.
weiter.
Da die zum Auskommen nötigen Margen dort viel niedriger sind lohnt sich
das.
> Das ist schlicht und> ergreifend B-Ware.
Hast Du dafür irgendwelche Belege oder Indizien außer dem Preis?
Gerd E. schrieb:> Weil der Markt in China anders funktioniert.
Jo...
Wir haben gerade CC1101-Funkmodule von CDSENET ausgiebig getestet.
Natürlich war die Befürchtung: gefälschte Chips, mieser Quarz und
billige Filterinduktivitäten. Alles mit Bravour bestanden, zu einem
Preis von 1,60$ @ 1000Stk. Dafür gibts hier nicht mal den nackten
CC1101.
Irgendwo gibts für Chips Fabriken, in der sie getestet werden und aus
denen defekte Exemplare rausfallen. Wobei diese Fabriken nicht zwingend
den Chipherstellern selbst gehören werden. Ein Chiphersteller hat
natürlich ein Interesse daran, dass die auch wirklich vernichtet werden,
weil Reklamationen zu seinen Lasten gehen. Einzelne Mitarbeiter solcher
Fabriken könnten das jedoch etwas anders sehen. Stellt sich also die
Frage, wie mit dem Schrott konkret verfahren wird.
Gerd E. schrieb:>> Das ist schlicht und ergreifend B-Ware.> Hast Du dafür irgendwelche Belege oder Indizien außer dem Preis?
Nein, es ist meine persönliche Einschätzung.
Indizien ja:
Zum Beispiel habe ich einige STM32F103C8T6 Chips mit angerosteten
Beinchen bekommen. Und unter einigen hundert besonders preisgünstigen
LED's sind mir einzelne mit anderer Farbe und/oder Helligkeit
aufgefallen. In einer großen Tüte Mikrotaster fand ich einzelne, bei
denen der obere Blech-Deckel an 1-2 Ecken nicht korrekt befestigt wurde.
Bei einem Paket Steckbrettern waren einzelne Kontaktfedern deformiert.
Bei Dupont Kabeln enthielten die Kabel zu viel stinkenden Weichmacher.
Ein Satz RS485 Module hatte anscheinend ein Bad in seifigem Wasser
genommen.
Ich habe schon eine Menge Bastelmaterial zu Schleuderpreisen bei
Aliexpress gekauft. Bisher hatte ich bei fast jeder Lieferung
irgendeinen deutlichen Mangel gefunden. Angesichtes der Preise, bin ich
insgesamt trotzdem zufrieden.
Immerhin haben alle Teile funktioniert. Es kommt mir so vor, als ob es
dort fleißige Leute gibt, die aus dem Müll die noch brauchbaren Teile
heraus sortieren. Vie vielen Jahren hatte sich meine Oma in Deutschland
auf eben diese Weite ordentlich was zur Rente dazu verdient. Sie
sortierte und montierte Schrauben, Lüsterklemmen, Kugelschreiber und
anderen Kleinkram.
Richtig interessant wird's beim H753 vs. H750. Die haben beide die Die
Id 450, aber 2 MByte vs. 128 kByte Flash. Und die Preisdifferenz ist
enorm.
Schwer vorstellbar, dass ST da nicht einen Riegel vorgeschoben hat.
Leider ist mir noch kein H750er über den Weg gelaufen ...
Stefanus F. schrieb:> Ich habe schon eine Menge Bastelmaterial zu Schleuderpreisen bei> Aliexpress gekauft.
Na dann wird ja deine Wohnung bereits voll Schrott sein
bis an die Decke.
Brauchst du einen Messy-Berater?
Stefanus F. schrieb:> Zum Beispiel habe ich einige STM32F103C8T6 Chips mit angerosteten> Beinchen bekommen.
Da könnte aber auch gut eine ungeeignete Lagerung bei einem
Zwischenhändler die Ursache gewesen sein, die die von ST ursprünglich
guten ICs nachträglich befallen hat.
> LED's
[...]
> Mikrotaster
[...]
> Steckbrettern
[...]
> RS485 Module
Meiner Erfahrung nach ist da ein sehr großer Unterschied zwischen diesen
eher einfachen Bauteilen und hoch komplexen wie Mikrocontrollern:
Taster, Steckbretter etc. werden in China auch von irgendwelchen
Hinterhof-Fabriken hergestellt. Bei manchen von denen ist die Qualität
so zweifelhaft, daß man die Teile hier direkt als Ausschuss wegwerfen
würde.
LEDs und einfachere ICs wie RS485-Module, Spannungsregler, 555-Timer,
etc. werden auch von chinesischen Fabs hergestellt. Im Gegensatz zu
westlichen Herstellern wie ST werden dort wirklich verschiedene Grades
produziert und selektiert und die B- und C-Ware dann für den
innerchinesischen Markt verwendet. Dann kommt noch hinzu daß diese Teile
auch von defekten Boards mit einfachsten Mitteln runtergelötet, neu
bedruckt und wieder verkauft werden.
Bei einfacheren Bauteilen hab ich schon so oft Fälschungen,
Recyclingware etc. bekommen. Da wundert mich mittlerweile nichts mehr.
Bei den komplexeren Teilen wie den Mikrocontrollern von ST hast Du aber
den Hersteller der eine saubere Qualitätskontrolle macht und sich
größere Mühe gibt die defekten Teile zu vernichten und sicherzustellen
daß die nicht auf den Markt kommen.
Ich habe trotz regelmäßigen Bestellungen direkt aus China via Aliexpress
und ebay noch nie einen defekten oder offensichtlich gefälschten
Mikrocontroller bekommen.
Also wat nu? Wie teste ich denn jetzt die oberen 64k in einem BluePill
Board / STM32F103C8T6?
Alle Bits auf 0 setzen und bei angenehmen 85°C warten bis sie umkippen,
oder wie?
Ich denke, wenn du mit dem Testen fertig bist, ist der Chip danach
wirklich für die Tonne, da verschlissen. Die Alterung von Flash
Speichern wird mit erhöhter Temperatur getestet, soweit ich weiß.
In der Praxis wird man wohl eher Stichproben nehmen und dann die ganze
Charge aussortieren, wenn die Stichprobe schlecht war.
Stefanus F. schrieb:> Ich denke, wenn du mit dem Testen fertig bist, ist der Chip danach> wirklich für die Tonne, da verschlissen.
Da das Flash jedes einzelnen Chips auf Bitfehler getestet werden muss,
wäre das etwas unökonomisch. ;-)
Solche obligatorischen Tests umfassen Funktionstests, aber keine Tests
auf Lebensdauer. Es geht dabei um lokale Fabrikationsfehler,
beispielsweise durch Verunreinigungen.
A. K. schrieb:> Da das Flash jedes einzelnen Chips auf Bitfehler getestet werden muss,> wäre das etwas unökonomisch. ;-)
In den ganzen Mikrocontrollern ist doch meines Wissens nach NOR-Flash
verbaut und soweit ich weiß gibt es da nicht solche Fertigungstoleranzen
mit Bitfehlern wie bei NAND-Flash. Der Preis dafür sind halt wesentlich
niedrigere Speicherdichten.
Bauform B. hatte ja damals dankenswerter Weise die Datei mit den Die-IDs
hier hochgeladen. Ich wollte jetzt mal nach aktuelleren µCs schauen und
habe dafür die Liste aktualisiert.
Die Die-IDs sind jetzt etwas anders abgelegt. Sie liegen jetzt in
einzelnen .xml-Dateien pro µC im Verzeichnis
plugins/com.st.stm32cube.common.mx_<version>/db/mcu
Ich hab die angehängte Datei wie folgt erstellt:
So, hier mal eine aktualisierte Version. Vielleicht hilft es ja dem
einen oder anderen durch die Beschaffungskrise zu manövrieren...
Die Quelldateien liegen jetzt in ./db/mcu und erzeugt hab ich die Datei
mit:
