Forum: Mikrocontroller und Digitale Elektronik Controller mit größerem Flash als angegeben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von stm32 (Gast)


Lesenswert?

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?

von Stefan P. (form)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von NichtWichtig (Gast)


Lesenswert?

Hier ist eine Möglichkeit benannt
Beitrag "Bluepill STM32F103C8T6 Board 128kb"

von Oliver S. (oliverso)


Lesenswert?

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

von STM32-Experte (Gast)


Lesenswert?

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.

von stm32 (Gast)


Lesenswert?

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.

von --- (Gast)


Lesenswert?

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

von stm32 (Gast)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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.

von Ingenieur (Gast)


Lesenswert?

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.

von Felix F. (wiesel8)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Alle STM32F10xX8 und STM32F10xXB haben die gleiche ChipID 
(DBGMCU_IDCODE) und sind daher der gleiche Chip.

von stm32 (Gast)


Lesenswert?

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.

von Felix F. (wiesel8)


Lesenswert?

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

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von stm32 (Gast)


Lesenswert?

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.

von STM32-Experte (Gast)


Lesenswert?

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.

von Erwin D. (Gast)


Lesenswert?

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?

von STM Apprentice (Gast)


Lesenswert?

STM32-Experte schrieb im Beitrag #5563554:
> Klappt einwandfrei. Mehrfach getestet.

Hatte ich beim BluePill (F103C8T6) auch schon erlebt.

von Bauform B. (bauformb)


Angehängte Dateien:

Lesenswert?

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

von STM Apprentice (Gast)


Lesenswert?

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?"

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

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!

von S. R. (svenska)


Lesenswert?

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?

von H.Joachim S. (crazyhorse)


Lesenswert?

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.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

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

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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?

von H.Joachim S. (crazyhorse)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von A. B. (Gast)


Lesenswert?

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

von Haus Meister (Gast)


Lesenswert?

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?

von Gerd E. (robberknight)


Lesenswert?

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.

von BitFragger (Gast)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Beim H743 vs H750 wird ST bestimmt Fuses setzen, die den oberen Flash 
dann unzugaenglich machen.

von Christopher J. (christopher_j23)


Lesenswert?

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.

von Gerd E. (robberknight)


Angehängte Dateien:

Lesenswert?

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

von Gerd E. (robberknight)


Angehängte Dateien:

Lesenswert?

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
Noch kein Account? Hier anmelden.