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.
:
Bearbeitet durch Moderator
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Alle STM32F10xX8 und STM32F10xXB haben die gleiche ChipID (DBGMCU_IDCODE) und sind daher der gleiche Chip.
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?
STM32-Experte schrieb im Beitrag #5563554: > Klappt einwandfrei. Mehrfach getestet. Hatte ich beim BluePill (F103C8T6) auch schon erlebt.
Bei CubeMX ist eine Liste aller(?) STM32 dabei und da steht ein DIE-Id drin. Ich hab' die mal nach DIE sortiert; es gibt nicht besonders viele:
1 | Familie versch. DIE |
2 | STM32 F0 5 |
3 | STM32 F1 7 |
4 | STM32 F2 1 |
5 | STM32 F3 5 |
6 | STM32 F4 10 |
7 | STM32 F7 3 |
8 | STM32 H7 1 |
9 | STM32 L0 4 |
10 | STM32 L1 5 |
11 | STM32 L4 5 |
Hamma letztes Jahr um diese Zeit schon durchgekaut. Hier kann man das mal nachlesen und mit einem Binary (für 128K) austesten. Beitrag "Re: STM32F103C8T6 Blue Pill Board: Mit ST-Link V2 an die 128kb Flash?"
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beim H743 vs H750 wird ST bestimmt Fuses setzen, die den oberen Flash dann unzugaenglich machen.
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:
1 | grep -o "DIE..." * | sed -e "s/\(.*\).xml:\(DIE.*\)/\2 \1/" | sort |
Stand ist: stm32cubeide_1.2.0_5034_20200108_0926 stm32cube.common.mx_5.5.0.201912201511
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:
1 | grep -o "DIE..." STM* | sed -e "s/\(.*\).xml:\(DIE.*\)/\2 \1/" | sort |
Stand ist CubeMX 6.3.0.
Bitte 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.