Gerd E. schrieb:> Vielen Dank für die Fotos.
Gerne!
Gerd E. schrieb:> Da hat sich also tatsächlich jemand die Mühe gemacht einen komplett> eigenen, in Richtung kompatiblen gehenden Die zu entwickeln. Ein GD32> kann es nicht sein, die sehen komplett anders aus (siehe u.a. bei> Zeptobars> https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices> ).>> Hätte nicht gedacht daß sich das lohnt.
In der Welt der ("neumodernen") Mikrocontroller bin ich nicht so
bewandert. Aber es könnte doch sein, dass (vermutlich in China) ein
Low-Cost-Controller entwickelt wurde und dabei weil es praktisch ist
sehr viele Anleihen beim STM32 genommen wurden. Als Fake-STM32 war der
entstehende Controller vielleicht gar nicht gedacht, sondern als
günstiger Eigenbau-STM32. Danach ist ein geschäftstüchtiger Mensch auf
die Idee gekommen etwas anderes auf das Package zu lasern und mehr Geld
zu verdienen. Auf Grund der Ähnlichkeit der Architektur fällt das dann
auch nicht gleich/immer auf.
Nur eine wage Theorie...
Karsten M. schrieb:> Bei Greaseweazle wird so etwas erwähnt, aber der angegebene Ordner> existiert nicht und blinky_test scheint dies nicht zu erfüllen?
Du musst greaseweazle downloaden, dann ist in der zip ein Ordner /alt,
in dem ein Hex-File ist: Blinky_Test-v0.11.hex (siehe im Anhang)
Richard K. schrieb:> Gerd E. schrieb:>> Vielen Dank für die Fotos.>> Gerne!
.
> Gerd E. schrieb:>> Da hat sich also tatsächlich jemand die Mühe gemacht einen komplett>> eigenen, in Richtung kompatiblen gehenden Die zu entwickeln. Ein GD32>> kann es nicht sein, die sehen komplett anders aus (siehe u.a. bei>> Zeptobars>> https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices>> ).>>>> Hätte nicht gedacht daß sich das lohnt.
.
> In der Welt der ("neumodernen") Mikrocontroller bin ich nicht so> bewandert. Aber es könnte doch sein, dass (vermutlich in China) ein> Low-Cost-Controller entwickelt wurde und dabei weil es praktisch ist> sehr viele Anleihen beim STM32 genommen wurden. Als Fake-STM32 war der> entstehende Controller vielleicht gar nicht gedacht, sondern als> günstiger Eigenbau-STM32. Danach ist ein geschäftstüchtiger Mensch auf> die Idee gekommen etwas anderes auf das Package zu lasern und mehr Geld> zu verdienen. Auf Grund der Ähnlichkeit der Architektur fällt das dann> auch nicht gleich/immer auf.> Nur eine wage Theorie...
Da ein STM32F103 aus ARM- und Peripherie-Ip gebaut wurde, die beide
Kaufbereitschaft sind, kann jemand anderer das Selbe kaufen und damit
kompatibles bauen. Nur STM darf man nicht draufschreiben.
Carl D. schrieb:> Da ein STM32F103 aus ARM- und Peripherie-Ip gebaut wurde, die beide> Kaufbereitschaft sind, kann jemand anderer das Selbe kaufen und damit> kompatibles bauen. Nur STM darf man nicht draufschreiben.
Stimmt, das kommt natürlich noch dazu.
Wäre jetzt interessant, ob es sich um einen bekannten oder einen
unbekannten Controller handelt und wie er seinen Weg in das Package
gefunden hat... Vielleicht würde das Package auch nachträglich
umgelabelt.
Man wird es wahrscheinlich nie herausfinden...
Richard K. schrieb:> Carl D. schrieb:>> Da ein STM32F103 aus ARM- und Peripherie-Ip gebaut wurde, die beide>> Kaufbereitschaft sind, kann jemand anderer das Selbe kaufen und damit>> kompatibles bauen. Nur STM darf man nicht draufschreiben.>> Stimmt, das kommt natürlich noch dazu.> Wäre jetzt interessant, ob es sich um einen bekannten oder einen> unbekannten Controller handelt und wie er seinen Weg in das Package> gefunden hat... Vielleicht würde das Package auch nachträglich> umgelabelt.> Man wird es wahrscheinlich nie herausfinden...
Ja, irgendwer hat das Beweismaterial verbrannt!
;-)
Gerd E. schrieb:> Vielen Dank für die Fotos.
Da schließe ich mich gleich mal an.
Gerd E. schrieb:> Ein GD32> kann es nicht sein, die sehen komplett anders aus (siehe u.a. bei> Zeptobars> https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices> ).
Da hätten dann ja auch auf wundersame Weise zwei Dice herauskommen
müssen ;)
Richard K. schrieb:> Wäre jetzt interessant, ob es sich um einen bekannten oder einen> unbekannten Controller handelt und wie er seinen Weg in das Package> gefunden hat...
Falls noch nicht geschehen könnte dir ja mal einer einen "originalen"
CKS32 von einem Bluepill zuschicken. Wenn der nicht passt, dann
vielleicht einer der beiden die bei LCSC gelistet sind.
Christopher J. schrieb:> Falls noch nicht geschehen könnte dir ja mal einer einen "originalen"> CKS32 von einem Bluepill zuschicken. Wenn der nicht passt, dann> vielleicht einer der beiden die bei LCSC gelistet sind.
Aus der Kategorie liegt aktuell nichts auf dem Stack.
Also wenn noch jemand einen interessanten Verwandten des STM32 besitzt
und für "die Wissenschaft" opfern will, immer her damit!
Carl D. schrieb:> Richard K. schrieb:>> Carl D. schrieb:>>> Da ein STM32F103 aus ARM- und Peripherie-Ip gebaut wurde, die beide>>> Kaufbereitschaft sind, kann jemand anderer das Selbe kaufen und damit>>> kompatibles bauen. Nur STM darf man nicht draufschreiben.>>>> Stimmt, das kommt natürlich noch dazu.>> Wäre jetzt interessant, ob es sich um einen bekannten oder einen>> unbekannten Controller handelt und wie er seinen Weg in das Package>> gefunden hat... Vielleicht würde das Package auch nachträglich>> umgelabelt.>> Man wird es wahrscheinlich nie herausfinden...>> Ja, irgendwer hat das Beweismaterial verbrannt!
Nochmals genau schauen, vielleicht hat er am Tatort seinen Reisepass
verloren, welcher bestimmt das Feuer überstanden hat.
Tippgeber schrieb:> Du musst greaseweazle downloaden, dann ist in der zip ein Ordner /alt,> in dem ein Hex-File ist: Blinky_Test-v0.11.hex (siehe im Anhang)
Danke - dies ist mir inzwischen ebenfalls aufgefallen.
Allerdings hat das Thema Testprogramm für Klone erstaunlicherweise kaum
Resonanz gefunden.
Wenn man einen Testockel bauen würde bei dem die Ports nach einem
bestimmten Raster verbunden sind und die PWM-Ausgänge über ein RC-Glied
jeweils zu einem AD-Eingang geführt werden, könnte man doch schon Mal
einen recht großen Umfang der Hardware und Funktionen überprüfen oder
etwa nicht?
Noch einmal zu dem leidigen Thema Preis:
Für $14,07 bekommt man einen zuverlässig funktionieren OrangePi mit H3
Quad-core und 512 MB zu kaufen.
https://www.aliexpress.com/item/32603308880.html
Für $24,45 ist es schon ein 64 Bit H6 Quad-core und 1 GB Hauptspeicher.
https://www.aliexpress.com/item/32848891030.html
So eine Lösung auf der ein komplettes Linux läuft ziehe ich in dieser
Preisregion einem STM32 Midrange-ARM vor.
Damit erhälte ich dann komfortable Lösungen direkt mit Datenbank und
LAN-Anbindung.
Einziges Manko ist die Echtzeitfähigkeit der Standard-Distributionen,
aber dafür gibt es ja 4 Kerne mit echter Leistungsfähigkeit.
Karsten M. schrieb:> Für $14,07 bekommt man einen zuverlässig funktionieren OrangePi mit H3> Quad-core und 512 MB zu kaufen.
Das sind aber auch chinesische Chips ohne Dokumentation, abhängig von
binary blobs. Warum ist das besser als ein Fake-STM32? Wenn schon musst
du mit so etwas wie einem Beagle Bone Black (ca. 60€) vergleichen, der
einen TI Sitara SoC enthält, welcher ein westliches Produkt mit nahezu
vollständiger Doku und Qualitäts Garantie ist. Oder (bald?) mit etwas
STM32MP-basiertem...
Programmierer schrieb:> Das sind aber auch chinesische Chips ohne Dokumentation, abhängig von> binary blobs. Warum ist das besser als ein Fake-STM32? Wenn schon musst> du mit so etwas wie einem Beagle Bone Black (ca. 60€) vergleichen, der> einen TI Sitara SoC enthält, welcher ein westliches Produkt mit nahezu> vollständiger Doku und Qualitäts Garantie ist. Oder (bald?) mit etwas> STM32MP-basiertem...
Das stimmt so nicht ganz.
Es gibt schon einiges an Dokumentation dazu.
Z.B. http://linux-sunxi.org/Orange_Pi_One
Es ging lediglich darum zu vergleichen welche Hardware-Lösungen mit
welcher Leistung für um die $20 zu bekommen sind.
Die OrangePi's haben bislang eine brauchbare Qualität gezeigt und die
Distributionen von https://www.armbian.com laufen immer besser.
Die Hx CPU's sind zumindest legale unter Lizenz in China produzierte
Chips und keine Klone von irgendwas.
Mikrocontroller mit Applikationsprozessoren zu vergleichen finde ich
unpassend.
Alles was in irgendeiner Form geringe Latenz, Echtzeitfähigkeit,
geringen Energiebefarf usw. braucht ist mit Mikrocontrollern wesentlich
besser beraten.
So ein Linux ist auch deutlich wartungsintensiver als nur ein einziges
bare-Metal C/C++ Programm.
Will man ein komplettes Betriebssystem (ggf. mit Sicherheitslücken weil
der Kernel für solche Teile nur selten Updates bekommt) auf ALLEN
Geräten haben? Eher nicht...
Karsten M. schrieb:> Das stimmt so nicht ganz.> Es gibt schon einiges an Dokumentation dazu.
Ein Prozessor der 100x komplexer als ein STM32 ist braucht also nur ein
Hundertstel der Doku? Vergleich das mal mit der Doku von TI Sitara.
Karsten M. schrieb:> Die OrangePi's haben bislang eine brauchbare Qualität gezeigt
Meine Fake-STM32 auch...
Kortex schrieb:> Mikrocontroller mit Applikationsprozessoren zu vergleichen finde ich> unpassend.
Das sowieso...
Ein OrangePi ersetzt mir in keinem Fall einen STM32F103 - selbst wenn er
1$ kostet.
Es geht doch darum, dass man STM's bestellt, aber Fälschungen erhält.
Das sind auch keine Klone, da sie sich anders Verhalten als richtige
STMs.
Um das abzustellen, sollte man dafür sorgen, dass das sich der Verkauf
von Fälschungen für den Händler nicht lohnt. Dazu sollte man ihn (z.B.
bei Aliexpress) anschwärzen und das Geld zurückfordern. Dazu wären
Beweise für eine Fälschung hilfreich. Leider helfen hierzu viele Infos
in diesem Thread (noch) nicht wirklich: Nur weil sich zwei Chips
unterschiedlich verhalten/aussehen, müssen es schließlich keine
Fälschungen sein.
Aus diesem Grund möchte ich nochmals auf die Seite
https://www.blaatschaap.be hinweisen (s.o. in diesem Thread): Die
ROM-Table der Chips enthält eine Hersteller-ID. Falls diese nicht
"STMicroelectronics" ist, dann ist es eine Fälschung. Theoretisch könnte
die ID auch gefälscht sein. Aber auf dem Hinterhof gingen solche
Fälschungen (vermutlich) nicht und Fälschungen im größerem Stil wären
für STMicroelectronics reizvoller zu verfolgen und Fälscher möchten
nicht ihre Fabrik verlieren.
Wie man die ID ausliest und den Hersteller ermittelt ist in
"https://www.blaatschaap.be"; beschrieben. Dahinter verbergen sich
anscheinend Infos aus dem "CoreSight Components Technical Reference
Manual" und den Hersteller-Tabellen aus dem "JEDEC Standard
Manufacturer's Identification Code"-Dokument.
Auf bitte von Uwe B. (s.o.) hier nun die IDs meiner Chips:
Karsten M. schrieb:> Noch einmal zu dem leidigen Thema Preis:> Für $14,07 bekommt man einen zuverlässig funktionieren OrangePi mit H3> Quad-core und 512 MB zu kaufen.> Für $24,45 ist es schon ein 64 Bit H6 Quad-core und 1 GB Hauptspeicher.> https://www.aliexpress.com/item/32848891030.html>> So eine Lösung auf der ein komplettes Linux läuft ziehe ich in dieser> Preisregion einem STM32 Midrange-ARM vor.
Da vergleichst du aber Äpfel mit Birnen. Das ist so als würdest du in
einer Diskussion um Enduro-Mopeds für ein Rennen über den
Schlamm-Parcourt einen Panzer vorschlagen. Weil der ja besser
motorisiert ist und mit dem Kettenfahrwerk nirgends stecken bleibt.
Daniel V. schrieb:> Dazu sollte man ihn (z.B.> bei Aliexpress) anschwärzen und das Geld zurückfordern.
In den Kundenrückmeldungen bei Ali findet man bei einigen Händlern auch
Meldungen zu nicht Original, die kann man also schonmal meiden.
Andere geben mittlerweile in der Produktbeschreibung einen CKS an.
Daniel V. schrieb:> Die Chips #1 und #2 wurden von mir bei unterschiedlichen> Aliexpress-Händlern gekauft.
Was beweisen würde, daß man auch bei Ali Originale zu günstigen Preisen
kaufen kann.
> Der Chip #3 behauptet von "ARM Ltd." hergestellt zu sein(?).
Der Aufdruck "CKS32F103C8T6" (wohl eher "CS32F103C8T6") versucht gar
nicht erst, einen STM32F103 vorzutäuschen. Welchen Status die Chips von
CKS haben (ob sie z.B. eine Lizenz von ARM haben) ist ungewiß. Dito
inwieweit sie funktionieren.
Wenn der Händler dir Boards mit STM32F103 bewirbt/verkauft, dann aber
CS32F103 geliefert hat, ist das aber auch unerheblich. "Ware nicht wie
beschrieben" reicht dann als Grund für die Retoure.
Axel S. schrieb:> ...wohl eher "CS32F103C8T6"...
Der Aufdruck ist tatsächlich "CKS32F103C8T6".
Der CKS32 ist in einen meiner STLink-V2 verbaut. Ich beanstande da
nichts. Mir ging es um den ROM-Table-Eintrag.
Zu den ganzen Antworten oben:
Das ist alles richtig aber andererseits gar nicht das Thema.
Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man
einen STM32 Controller verwendet und keinen z.B. von Atmel oder
Microchip.
Dies führt dann zu der Frage welche ARM-CPU gebrauchsfertig für welchen
Preis zu bekommen ist.
Das Fazit dieser Diskussion ist die interessante Frage, warum
ausgerechnet die preiswerteren STM32 MCU's gefälscht werden, während die
deutlich größeren Hx CPU's in Lizenz produziert werden.
Bei den Preisen für die Orange-Pi's kann so eine H3 CPU auf jeden Fall
nicht viel Kosten und dennoch können diese für den Preis zu einem
gleichbleibenden Qualitätsniveau angeboten werden.
Bei den Blue-Pill's ist die Hardware echte Lotterie!
Das mit den ID's bei den Fälschungen ist ebenfalls recht erstaunlich,
aber hilft eigentlich nur die Fälschungen festzustellen.
Interessanter ist doch die Frage ob die MCU trotzdem korrekt arbeitet
oder nicht?
Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus so
viel kostet wie ein neues IC beim Produzent, kann doch keiner ernsthaft
erwarten ein neues Original zu erhalten.
Karsten M. schrieb:> Das Fazit dieser Diskussion ist die interessante Frage, warum> ausgerechnet die preiswerteren STM32 MCU's gefälscht werden
das dürfte doch klar sein: die Bluepill gab es jahrelang mit org. CPUs
und die wurden immer bekannter und beliebter. Jetzt ist ist der billige
Nachschub zu Ende und anstatt teurer Originale nehmen die Chinesen
lieber eigene Produktion. Wenn die in 80-90% der Anwendungen auch
funktioniert, who cares?
Karsten M. schrieb:> Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus so> viel kostet wie ein neues IC beim Produzent, kann doch keiner ernsthaft> erwarten ein neues Original zu erhalten.
Auch die Originale sind in Asien mitunter erheblich billiger als hier,
weil einfach viel größere Mengen davon verarbeitet werden und weil
vieles davon auch dort produziert wird und deshalb die Wege von der
Chipfabrik zum Bestücker kürzer sind.
Ich habe leztes Jahr mal bei Bosch nachgefragt, wie wahrscheinlich es
ist, dass es sich bei den BME280 um Fälschungen handelt, die man bei
AliExpress auf Platinen samt Hühnerfutter für weniger als 2 Euro
bekommt, während der nackte Chip hier beim Distributor in Kleinmengen
5-6 Euro kostet. Die Antwort war, dass Fälschungen eher unwahrscheinlich
sind, vor allem wenn die Druckmessung plausible Werte liefert, und dass
der Preis für den asiatischen Markt durchaus realistisch ist.
Karsten M. schrieb:> Das ist alles richtig aber andererseits gar nicht das Thema.
Da gehen unsere Meinungen auseinander. Deutlich.
> Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man> einen STM32 Controller verwendet und keinen z.B. von Atmel oder> Microchip.
Nein, darum geht es nicht. Es geht darum, was man tun kann (und sollte)
wenn man ein Bauteil oder eine Platine gekauft hat, die damit beworben
wird daß ein STM32xxx drauf ist, aber etwas anderes geliefert bekommt.
> Das Fazit dieser Diskussion ist die interessante Frage, warum> ausgerechnet die preiswerteren STM32 MCU's gefälscht werden
Das ist doch trivial: das Produkt "Bluepill" hat einen ausgezeichneten
Ruf und wird den Händlern förmlich aus den Händen gerissen. Natürlich
nutzen Trittbrettfahrer das aus. Das ist bei Arduino nano genauso.
> Das mit den ID's bei den Fälschungen ist ebenfalls recht erstaunlich,> aber hilft eigentlich nur die Fälschungen festzustellen.> Interessanter ist doch die Frage ob die MCU trotzdem korrekt arbeitet> oder nicht?
Das ist auch eine interessante Frage, aber nicht in diesem Zusammenhang.
Wenn ein Händler ein "Bluepill" Board anbietet und dazu schreibt, daß
ein z.B. CS32F103 da drauf ist - dann ist das eine relevante Frage.
Denn die Antwort entscheidet darüber ob man das kaufen will (und ob man
den gleichen Preis bezahlen will wie für eins mit STM32).
> Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus so> viel kostet wie ein neues IC beim Produzent, kann doch keiner ernsthaft> erwarten ein neues Original zu erhalten.
Diese Logik funktioniert nicht. Es wurden ja jahrelang Bluepill Boards
zu derart geringen Preisen verkauft. Und die µC da drauf sind nach allem
was man weiß, auch echt. Keiner weiß warum die so billig sind. Aber es
gibt etliche Möglichkeiten:
- Chips die irgendwelche Nebenkenngrößen nicht einhalten und von ST
eigentlich als Ausschuß entsorgt würden, sind im Graumarkt gelandet
- die Fab in Malaysia oder China hat "Überstunden" gemacht und die
erzeugte Ware auf den Graumarkt geworfen
- ein Großkunde hat sich bei ST eingedeckt und ist Pleite gegangen, die
Chips aus der Konkursmasse sind auf dem Graumarkt gelandet
In all diesen Fällen (ohne Anspruch auf Vollständigkeit) wären das echte
ST-Chips, die unter dem Mikroskop und mit den meisten Tests als
Originale durchgehen würden.
Axel S. schrieb:> Da gehen unsere Meinungen auseinander. Deutlich.
Nicht wirklich.
Der Gedankengang mit den Orange-Pi's war leider irreführend und
off-topic.
Er sollte nur aufzeigen das es ab ca. $20 noch andere Hardware für
Lösungen gibt und das diese dann nicht mit Klonen, sondern eigenen
klaren CPU Typen und Lizenzen arbeitet.
>>> Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man>> einen STM32 Controller verwendet und keinen z.B. von Atmel oder>> Microchip.>> Nein, darum geht es nicht. Es geht darum, was man tun kann (und sollte)> wenn man ein Bauteil oder eine Platine gekauft hat, die damit beworben> wird daß ein STM32xxx drauf ist, aber etwas anderes geliefert bekommt.
Nachweisen das es sich um eine minderwertige Fälschung handelt.
Dafür ist die ID schon Mal ein guter Ansatz.
Wenn die Blue-Pill trotz korrekter ID nicht korrekt tickt, wäre ein
standardisierter Hardware-Test von Vorteil um nachweisen zu können, daß
die Ware defekt ist.
Wenn man sich nicht rumärgern möchte, dann ist die vorgeschlagene
Platine von RobotDyn ein guter Kompromiß:
https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-with-arduino-bootloader.html
Karsten M. schrieb:> Interessanter ist doch die Frage ob die MCU trotzdem korrekt arbeitet> oder nicht?
Offensichtlich ist das nicht - oder zumindest nicht immer - der Fall.
Das fängt damit an, das sich manche grundsätzlich nicht wie gewohnt wie
ein STM32 flashen lassen, über disfunktionale DMA, bis hin zu anderen
Ausführungszeiten für Code, was dann etwaiges Bitbanging vermasselt.
Jetzt wäre es nur noch interessant, welcher Abkömmling welche Schwäche
hat und was genau eigentlich unter der Haube von den falsch deklarierten
Chips steckt.
Aus dem Grund schließe ich mich mal der Bitte von Uwe Bonnes an. Sehr
nett wäre es, wenn mal jemand den Test mit einem falsch deklarierten
F103C8 durchführen würde, also mit einer der zuvor genannten
Frank M. schrieb:> die im Eingangsposting erwähnten Fakes mit Seriennummer "...MYS 807"> bzw. "...MYS 901"
Das würde eventuell etwas Licht ins Dunkel bringen.
Karsten M. schrieb:> Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man> einen STM32 Controller verwendet und keinen z.B. von Atmel oder> Microchip.
Schau Dir nochmal die Titelzeile des Threads an.
Karsten M. schrieb:> warum ausgerechnet die preiswerteren STM32 MCU's gefälscht werden, während die> deutlich größeren Hx CPU's in Lizenz produziert werden.
Das liegt doch auf der Hand: Die sind einen sind um Welten einfacher
(wenigstens ungefähr) nachzubauen, als die anderen.
> Interessanter ist doch die Frage ob die MCU trotzdem> korrekt arbeitet oder nicht?
Ich habe das Gefühl, dass du nicht einmal die Beiträge vom
Threadersteller gelesen hast. Mangelhafte Funktion war der Auslöser, die
Echtheit des Chips in Frage zu stellen!
> Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus> so viel kostet wie ein neues IC beim Produzent, kann doch keiner> ernsthaft erwarten ein neues Original zu erhalten.
Preise schwanken und sind Verhandlungssache. Nur weil ich für den Chip
etwa 1€ bezahlen muss, heißt das noch lange nicht, dass ein chinesischer
Großabnehmer ebenfalls 1€ bezahlen muss. Der könnte die gleichen Chips
in Original durchaus für 20 Cent bekommen.
Dazu kommt, dass die Chips teilweise aus anderen Geräten Recycelt
wurden. Das machen die auch mit anderen Bauteilen.
Und dann gibt es da noch Ausschussware, die womöglich doch verkauft
wird. Zum Beispiel Chips die nicht den ganzen Spannungsbereich oder
Temperaturbereich abdecken, den sie sollten. Für Hobbybastler ist das
oft unkritisch.
Es kommt auch vor, dass eine ganze Charge weg geworfen wird, weil jeder
zehnte Chip darin defekt ist. Ein fleißiger Geschäftsmann mag diese
billig aufkaufen und doch verbauen. Dann testet er sie entweder einzeln
oder nimmt in Kauf, dass eine gewisse Anzahl von seinen Kunden
reklamiert wird.
Karsten M. schrieb:> Axel S. schrieb:>>>> Nein, darum geht es nicht. Es geht darum, was man tun kann (und sollte)>> wenn man ein Bauteil oder eine Platine gekauft hat, die damit beworben>> wird daß ein STM32xxx drauf ist, aber etwas anderes geliefert bekommt.>> Nachweisen das es sich um eine minderwertige Fälschung handelt.
Richtig. Was entweder trivial ist (falsche Beschriftung auf dem Chip)
oder eben weniger trivial.
> Dafür ist die ID schon Mal ein guter Ansatz.
Nicht für die Reklamation. Für dich und mich mag das ein gangbarer Weg
sein. Aber glaubst du ernsthaft, daß du damit jemanden aus der
Reklamations-Abteilung von Ali-Express überzeugst? Das ist eine
Handelsplattform ähnlich wie Amazon. Die wissen mit an Sicherheit
grenzender Wahrscheinlichkeit gar nicht, was für ein Produkt das ist,
das du gerade reklamierst. Wenn du da mit einer "id" kommst, kriegst du
als Antwort wahrscheinlich etwas wie "What 'Id' do you mean? A
passport?"
Wenn du hingegen ein Foto des gelieferten Teils zeigst, auf dem die
Beschriftung des Bauteils zu lesen ist. Und wenn die dann entweder
nicht STM32F103... ist oder wenn die Beschriftung zwar echt aussieht,
die Chargen-Nummer aber eine ist, die der Hersteller ST selber als
Fälschung bezeichnet, dann ja dann hast du gute Chancen daß der
Sachbearbeiter sagt "Jo, das sieht nicht koscher aus, im Zweifel ist der
Kunde König. Der Kauf wird rückabgewickelt."
> Wenn die Blue-Pill trotz korrekter ID nicht korrekt tickt, wäre ein> standardisierter Hardware-Test von Vorteil um nachweisen zu können, daß> die Ware defekt ist.
Das ist natürlich immer richtig. Früher, in der guten alten Zeit™ gab es
etwas, das nannte sich "Wareneingangskontrolle".
Axel S. schrieb:> Wenn du da mit einer "id" kommst, kriegst du> als Antwort wahrscheinlich etwas wie "What 'Id' do you mean? A> passport?"
Dann wird man halt genauer: Der im Chip abgelegte "Standard
Manufacturer’s Identification Code" ("JEP106AV") ist falsch.
Axel S. schrieb:> Wenn du hingegen ein Foto des gelieferten Teils zeigst, auf dem die> Beschriftung des Bauteils zu lesen ist. Und wenn die dann entweder> nicht STM32F103... ist oder wenn die Beschriftung zwar echt aussieht,> die Chargen-Nummer...
Wenn man eine Fälschung an der Aufschrift einfach erkennen kann, dann
ist die Sache natürlich trivial. Wenn es nicht so einfach ist, dann
musst Du es den Aliexpress-Mitarbeiter doch auch "erkären". Wenn dazu
erst eine Bestätigung von "STMicroelectronics" erforderlich ist, dann
ist das Ganze schlicht nicht praktikabel.
Wenn hingegen der im Chip abgelegte "Standard Manufacturer’s
Identification Code" ("JEP106AV") falsch ist, dann kann Aliexpress das
nicht ignorieren. Die Fälschung ist dann nur nicht visuell erkennbar -
mehr nicht.
Voraussetzung wäre aber, dass "STMicroelectronics" schriftlich
bestätigt, dass tatsächlich alle STM32F103 diesen Code abgelegt haben.
Eine weitere Voraussetzung ist, dass Fälscher nicht auch dieses
"schamlos" fälschen. :-)
Daniel V. schrieb:> Axel S. schrieb:>> Wenn du da mit einer "id" kommst, kriegst du>> als Antwort wahrscheinlich etwas wie "What 'Id' do you mean? A>> passport?">> Dann wird man halt genauer: Der im Chip abgelegte "Standard> Manufacturer’s Identification Code" ("JEP106AV") ist falsch.
Und das versteht der Chinese dann?
>> Wenn du hingegen ein Foto des gelieferten Teils zeigst, auf dem die>> Beschriftung des Bauteils zu lesen ist. Und wenn die dann entweder>> nicht STM32F103... ist oder wenn die Beschriftung zwar echt aussieht,>> die Chargen-Nummer...>> Wenn man eine Fälschung an der Aufschrift einfach erkennen kann, dann> ist die Sache natürlich trivial. Wenn es nicht so einfach ist, dann> musst Du es den Aliexpress-Mitarbeiter doch auch "erkären". Wenn dazu> erst eine Bestätigung von "STMicroelectronics" erforderlich ist
Dann lies doch nochmal den Eröffnungspost.
Axel S. schrieb:>> Dann wird man halt genauer: Der im Chip abgelegte "Standard>> Manufacturer’s Identification Code" ("JEP106AV") ist falsch.>> Und das versteht der Chinese dann?
JEP106AV:
"JEDEC standards and publications are designed to serve the public
interest through eliminating
misunderstandings between manufacturers and purchasers, facilitating
interchangeability and
improvement of products, and assisting the purchaser in selecting and
obtaining with minimum
delay the proper product for use by those other than JEDEC members,
whether the standard is to
be used either domestically or internationally. "
Mit "Will ich nicht verstehen - ignorier ich." wird sich Aliexpress
keinen Gefallen tun. So blöd sind die nicht.
Axel S. schrieb:>>> Wenn du hingegen ein Foto des gelieferten Teils zeigst, auf dem die>>> Beschriftung des Bauteils zu lesen ist. Und wenn die dann entweder>>> nicht STM32F103... ist oder wenn die Beschriftung zwar echt aussieht,>>> die Chargen-Nummer...>>>> Wenn man eine Fälschung an der Aufschrift einfach erkennen kann, dann>> ist die Sache natürlich trivial. Wenn es nicht so einfach ist, dann>> musst Du es den Aliexpress-Mitarbeiter doch auch "erkären". Wenn dazu>> erst eine Bestätigung von "STMicroelectronics" erforderlich ist>> Dann lies doch nochmal den Eröffnungspost.
Für diese Seriennummer "Seriennummer 991KA 93 MYS 807" hätten wir das
nun geklärt. Dann ist ja gut...
Christopher J. schrieb:> Das fängt damit an, das sich manche grundsätzlich nicht wie gewohnt wie> ein STM32 flashen lassen, über disfunktionale DMA, bis hin zu anderen> Ausführungszeiten für Code, was dann etwaiges Bitbanging vermasselt.> Jetzt wäre es nur noch interessant, welcher Abkömmling welche Schwäche> hat und was genau eigentlich unter der Haube von den falsch deklarierten> Chips steckt.>> Aus dem Grund schließe ich mich mal der Bitte von Uwe Bonnes an. Sehr> nett wäre es, wenn mal jemand den Test mit einem falsch deklarierten> F103C8 durchführen würde, also mit einer der zuvor genannten>> Das würde eventuell etwas Licht ins Dunkel bringen.
Dies bezieht sich wohl auf den Post mit folgendem Link?
https://www.blaatschaap.be/?p=95
Leider ist meine Erfahrung in der Programmierung der STM32F103C8T6 noch
nicht sehr groß (Anfänger).
Solange man eine DMA noch nicht benutzt hat, kann einem kaum ein Fehler
in dieser auffallen. ;-)
Daher wäre eine ausführbare Software direkt zum flashen und testen der
Blue-Pills von Vorteil - wie bereits mehrfach vorgeschlagen.
Es sind auf jeden Fall einige Testexemplare vorhanden, die zu
unterschiedlichen Zeiten bestellt worden sind.
Wie wird denn diese "Minderfunktion" der Fälschungen erklärt? Ich kann
das nicht so recht glauben. WENN dann wird da Ausschuss verkauft, der
dann meist in Randbereichen der Spec diese nicht mehr erfüllt, oder
bestimmte Teile ganz defekt sind.
Nur sind das dann nicht immer die gleichen Teile und nicht immer die
gleichen Probleme.
Es klingt sehr weit hergeholt, dass da jemand einen kompletten Nachbau
from Scratch macht, und dieser hat dann nur ganz bestimmte
Unzulänglichkeiten unter ganz bestimmten, aber immer gleichen,
Bedingungen.
Cyblord -. schrieb:> Es klingt sehr weit hergeholt, dass da jemand einen kompletten Nachbau> from Scratch macht, und dieser hat dann nur ganz bestimmte> Unzulänglichkeiten unter ganz bestimmten, aber immer gleichen,> Bedingungen.
Jein, die Originale haben ja auch kleine Unzulänglichkeiten, darüber
werden Bücher, äh, errata-PDFs geschrieben.
Erster Test:
** Blinky Test **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/Greaseweazle
Serial = ff52:066b:8275:5554:5224:8114
Flash Size = 64kB
Device ID = 0x0000
Revision = 0x0000
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop).........................
Die Bezeichnung auf dem Chip ist kaum zu lesen, da die Oberfläche
scheinbar gesandstrahlt wurde.
Karsten M. schrieb:> DMA Test #1... OK> DMA Test #2... OK> DMA Test #3... OK> DMA Test #4... OK
Das ist nicht weiter verwunderlich. Die Fakes, um die es hier geht,
haben Vertiefungen an den Ecken. Fotos und Quellen dazu wurden hier
schon gepostet. Diese steigen dann beim DMA-Test aus mit spurious
Interrupts.
Cyblord -. schrieb:> Es klingt sehr weit hergeholt, dass da jemand einen kompletten Nachbau> from Scratch macht, und dieser hat dann nur ganz bestimmte> Unzulänglichkeiten unter ganz bestimmten, aber immer gleichen,> Bedingungen.
Hättet du den Thread richtig gelesen, dann würdest du sowas falsches
nicht schreiben. Das wurde bereits analysiert und bewiesen, sogar
Bildmaterial des Die Layouts veröffentlicht.
Cyblord -. schrieb:> Es klingt sehr weit hergeholt, dass da jemand einen kompletten Nachbau> from Scratch macht,
Das ist bewiesenes Faktum und wird auf mehreren Seiten im Netz
diskutiert, u.a. hier:
https://www.blaatschaap.be/?p=120Cyblord -. schrieb:> und dieser hat dann nur ganz bestimmte> Unzulänglichkeiten unter ganz bestimmten, aber immer gleichen,> Bedingungen.
Was genau ist daran verwunderlich, dass zwei ähnliche Chips von zwei
verschiedenen Herstellern sich reproduzierbar in immer derselben Art und
Weise unterscheiden?
Wäre es anders, hätte ja mindestens einer von beiden seinen
Fertigungsprozess nicht im Griff.
Fortsetzung zu Beitrag "Re: STM32F103C8T6 - Fälschung von ST bestätigt"
Gleiche Blue-Pill, aber dieses Mal Test mit
https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8-diags.html
istm32id
Die xy coords: 107741010
Wafer Number: 117
Lot_num ascii encoded [23:0]: 0x00555482 | U T .
Lot_num ascii encoded [55:24]: 0x81145224 | . . R $
Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~
* Will this work with non STM32F103R8 chips << Not guaranteed
* How many times can the 't' test be safely run << 1000 times at least
* The Flash Data View is too fast << Use your terminal loging facility
& capture it
* Will this test harm my chip << No
* How can I view the current chip memory status << Quit the Menu and
enter 'free'
* What was the Test Kit made with << The Forth Programming Language
* How do I find other programs I can run << Quit the Menu and enter
'words4'
* Can I write other programs, blink a LED << Yes, quit the Menu and
enter 'gpioc.'
* Learn more <<
https://mecrisp-stellaris-folkdoc.sourceforge.io/quickstart.html
This diagnostic program written by Terry Porter <terry@tjporter.com.au>
https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8-diags.html
Get Mecrisp-Stellaris Forth:
https://mecrisp-stellaris-folkdoc.sourceforge.io
Mecrisp-Stellaris created by Matthias Koch
Es ist wirklich witzig, da man nun ein komplettes arbeitendes Forth auf
der Blue-Pill zur Verfügung stehen hat.
Hier noch eine weitere Blue-Pill:
** Blinky Test **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/Greaseweazle
Serial = ff48:066e:6677:5154:5448:8119
Flash Size = 64kB
Device ID = 0x0000
Revision = 0x0000
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop)...................................
stm32id
Die xy coords: 107937608
Wafer Number: 119
Lot_num ascii encoded [23:0]: 0x00515466 | Q T f
Lot_num ascii encoded [55:24]: 0x81195448 | . . T H
Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~
Wie man sieht haben beide Blue-Pills jeweils 128 KB Flash.
Was könnt Ihr bezüglich des Typs aus den ID's herauslesen?
Und noch eine weitere 3. Blue-Pill - ähnlich wie die 2. aber mit
gravierter Charge 990DY 0193 MYS 99 821:
** Blinky Test **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/Greaseweazle
Serial = ff37:066e:524e:3332:5430:4313
Flash Size = 64kB
Device ID = 0x0000
Revision = 0x0000
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop)..........................
stm32id
Die xy coords: 107937591
Wafer Number: 78
Lot_num ascii encoded [23:0]: 0x00333252 | 3 2 R
Lot_num ascii encoded [55:24]: 0x43135430 | C . T 0
Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~
Ein weiterer Link zum Thema:
https://mecrisp-stellaris-folkdoc.sourceforge.io/rants.html#rant-blue-pill
Some STM32F103 Problems
Problem Limitation
======== ==========
CAN Bus Shares memory with the usb hardware, which means that
usb and canbus cannot be enabled at THE SAME TIME
Serial Comms NO AUTOBAUD
USB Shares memory with the canbus hardware, which means that usb
and can cannot be enabled at THE SAME TIME.
USB must use a CRYSTAL unlike later stm32 chips which use only a
internal RC clock for USB
Digital to Analogue Converter DOESN’T have one
GPIO I/O port registers Have to be accessed as 32-bit words,
half-word or byte accesses are NOT allowed. Very CONFUSING to configure.
GPIO I/O port register Very CONFUSING to configure because of
GPIOx_CRH and GPIOx_CRL. Cortex-M0 is MUCH more logical making config
trivial.
I2C There are SIX pages of ERRATA for the I2C peripheral
DFU NO DFU bootloader (for flashing via USB)
DEBUG Debug registers CANNOT be read by user software.
Workaround: none. Want to read the Device ID via a program ? too bad!
Karsten M. schrieb:> Some STM32F103 Problems
Bei der Aufzählung handelt es sich aber um Nachteile von echten
STM32F103 im Vergleich zu neueren STM32-Generationen und nicht im
Nachteile von gefälschten STM32F103 im Vergleich zu echten.
Bis auf den letzten Punkt: die Testprogramme können die Device ID nicht
lesen und zeigen 0000 an. Dabei wäre gerade die ein Indiz (kein Beweis)
für Original vs 2nd Source vs Fälschung.
Karsten M. schrieb:> ~~~~~ ALL TESTS PASSED ~~~~~>> Wie man sieht haben beide Blue-Pills jeweils 128 KB Flash.
Das ist normal, ST lieferte bisher die STM32F103C8T6 immer mit 128 KB
Flash aus, von denen per ST-Link aber immer nur 64KB nutzbar waren. An
die obere 64KB-Hälfte kommt man nur per Bootloader dran.
Es wurde schon vor vielen Jahren gemunkelt, dass ST hier umgelabelte
STM32F103CB ausliefert, welche den Flash-Test in der oberen Hälfte nicht
bestanden haben. So kann man 50% Ausschuss immer noch einer Verwendung
zuführen. Bisher hat aber tatsächlich noch kein User, der die oberen
64KB Flash getestet hat, tatsächlich einen Fehler feststellen können.
Ergo: Das sieht nach einem Original aus.
Karsten M. schrieb:> Ein weiterer Link zum Thema:> https://mecrisp-stellaris-folkdoc.sourceforge.io/rants.html#rant-blue-pill
Auch das bezieht sich auf das Original.
Bitte diesen Thread nicht verwässern mit Fakten zum Original-STM32F103.
Hier geht es um die Fakes, siehe Ausgangsposting.
**WARNING**: 10xx8/B device returned valid IDCODE! Fake?
9
Testing I2C1... [Fake Chip?] **FAILED**
10
Testing I2C2... [Fake Chip?] **FAILED**
11
Testing SPI1... OK
12
Testing SPI2... OK
13
Testing TIM1... OK
14
Testing TIM2... OK
15
Testing TIM3... OK
16
Testing TIM4... OK
17
DMA Test #1... [Spurious IRQ: Fake Chip?] **FAILED**
18
DMA Test #2... [Spurious IRQ: Fake Chip?] [Bad Data] **FAILED**
19
DMA Test #3... [Spurious IRQ: Fake Chip?] [Bad Data] **FAILED**
20
DMA Test #4... [Spurious IRQ: Fake Chip?] [Bad Data] **FAILED**
21
Testing 64kB Flash... OK
22
Enable TIM4 IRQ... OK
23
Testing 20kB SRAM (endless loop)...
Quelle:
Beitrag "Re: WordClock mit WS2812"
Hier hat das ein µC.net-User getestet mit einem Fake, der ihm
aufgefallen war, weil die WordClock die WS2812-LEDs nicht korrekt zum
Leuchten bringen konnte - wegen des obigen DMA-Fehlers.
Und ja, das sind die gleichen Fakes wie hier im Ausgangsposting
beschrieben. Das kann man im weiteren Verlauf des WordClock-Threads an
den Bildern und Beschreibungen zur Gehäuseform (Vertiefungen an den
Ecken, MYS-Code) klar erkennen.
Frank M. schrieb:> Es wurde schon vor vielen Jahren gemunkelt, dass ST hier umgelabelte> STM32F103CB ausliefert, welche den Flash-Test in der oberen Hälfte nicht> bestanden haben. So kann man 50% Ausschuss immer noch einer Verwendung> zuführen. Bisher hat aber tatsächlich noch kein User, der die oberen> 64KB Flash getestet hat, tatsächlich einen Fehler feststellen können.
Kein mir bekannter Hersteller macht echtes Binning bei solchen
niedrigpreisigen Controllern. Das lohnt sich erst bei Desktop-CPUs oder
GPUs mit Verkaufspreisen im dreistelligen Dollarbereich. D.h. bei Deinem
Chip werden nur die unteren 64kB getestet und der Rest wird ignoriert.
Je nach Controllertyp sperrt man die ungenutzten Bereiche, oder man
lässt das Programmiergerät anhand der Silicon ID entscheiden ob darauf
zugegriffen werden kann. Mit chipinterner Software (bzw Bootloader) kann
man das üblicherweise leicht umgehen. Mit gepatchten Definitionsfiles
für das Flashtool oft auch.
(zur Sicherheit nochmal der Hinweis: "kaputt" heisst bei Flash nicht nur
"ich kann nicht lesen was ich gerade geschrieben habe". Kaputt kann auch
bedeuten dass die Threshold Voltage nicht stimmt und damit der
spezifizierte Datenerhalt nicht gewährleistet ist. Dann bleibt das
Programm vielleicht nur 10 Jahre drin und nicht 30 Jahre.)
Das Gleiche gilt auch für Peripherie. Wenn auf dem Die ein CAN vorhanden
ist, Dein Derivat den offiziell aber nicht hat, dann ist er vorhanden
aber ungeprüft. Manche Hersteller deaktivieren Peripherieblöcke über
Fusebits, aber in den meisten Fällen kann man darauf zugreifen.
Wie es aussieht bleibt es also dabei mit einem Testprogramm die
Hardware-Funktionen einzeln zu testen und somit eine "Eingangskontrolle"
durchzuführen.
Hier noch die Testergebnisse von zwei Blue-Pills mit CKS32F103C8T6
** Blinky Test **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/Greaseweazle
Serial = 1406:0101:122a:4d35:4b31:004e
Flash Size = 128kB
Device ID = 0x0410
Revision = 0x2003
**WARNING**: 10xx8/B device returned valid IDCODE! Fake?
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop)...........................
stm32id
Die xy coords: 16847878
Wafer Number: 42
Lot_num ascii encoded [23:0]: 0x004D3512 | M 5 .
Lot_num ascii encoded [55:24]: 0x004E4B31 | . N K 1
Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~
======================================================================
** Blinky Test **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/Greaseweazle
Serial = 0936:0006:122a:4d35:4b31:004e
Flash Size = 128kB
Device ID = 0x0410
Revision = 0x2003
**WARNING**: 10xx8/B device returned valid IDCODE! Fake?
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop)..............
stm32id
Die xy coords: 395574
Wafer Number: 42
Lot_num ascii encoded [23:0]: 0x004D3512 | M 5 .
Lot_num ascii encoded [55:24]: 0x004E4B31 | . N K 1
Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~
Ein valider IDCODE zeigt korrekt an das es sich nicht um Original STM
MCU's handelt.
Funktional erfüllen diese aber scheinbar dennoch ihren Zweck.
Karsten M. schrieb:> Ein valider IDCODE zeigt korrekt an das es sich nicht um Original STM> MCU's handelt.> Funktional erfüllen diese aber scheinbar dennoch ihren Zweck.
Vielleicht sollte man beim Einkauf bei AliExpress lieber gleich nach
CKS32F103 oder GD32F103 suchen. Diese Chips wird wohl keiner fälschen.
Wie wird den I2C oder SPI oder xxx getestet?
Wie ist die Hardware drumrum aufgebaut um solche Aussagen zu treffen?
Wie wird die langsamere Abarbeitung erfaßt welche ich beobachtet habe?
Und aus welcher Ecke des µC läßt sich das begründen?
Wie schauts mit der SWD Schnittstelle aus die bei keinem meiner
FakePills läuft?
Hier ein Chip, der für mich original aussieht und laut Date Code Anfang
2017 produziert wurde. Er befindet sich auf einer BluePill alter Bauart
(raue Kanten, runder Taster, chaotische Pin-Beschriftung), die ich im
August 2017 oder Januar 2018 bestellt habe, also zu einer Zeit als von
Fakes noch lange keine Rede war.
Seine ID-Register sind auslesbar, alle anderen Tests besteht er aber.
Könnte es sein, dass ST den Bug irgendwann behoben hat, ohne das
Errata-Sheet zu aktualisieren?
[edit]
Ah, der Chip hat den Fehler doch, allerdings ist das Erratum etwas
missverständlich formuliert, denn User-Software kommt durchaus an den
Registerinhalt dran, sobald der Controller mal an einem Debugger hing.
Selbst nach Abstecken des Debuggers und Reset per Taster bleiben die
Register lesbar, erst ein Powercycle beendet den Zustand.
[/edit]
1
** Blinky Test **
2
** Keir Fraser <keir.xen@gmail.com>
3
** https://github.com/keirf/Greaseweazle
4
Serial = ff52:0672:6752:5353:1736:8717
5
Flash Size = 64kB
6
Device ID = 0x0410
7
Revision = 0x2003
8
**WARNING**: 10xx8/B device returned valid IDCODE! Fake?
NichtWichtig schrieb:> Wie wird den I2C oder SPI oder xxx getestet?>> Wie ist die Hardware drumrum aufgebaut um solche Aussagen zu treffen?>> Wie wird die langsamere Abarbeitung erfaßt welche ich beobachtet habe?> Und aus welcher Ecke des µC läßt sich das begründen?>> Wie schauts mit der SWD Schnittstelle aus die bei keinem meiner> FakePills läuft?
Ist alles NichtWichtig - wie der Name bereits sagt. :-)
Deshalb ja mein Vorschlag für ein Testprogramm und einer einfachen
standardisierten Außenbeschaltung, wo Eingänge mit Ausgängen verbunden
sind, etc ...
Dann gibt es realere Aussagen was funktioniert.
Frank M. schrieb:> Das ist normal, ST lieferte bisher die STM32F103C8T6 immer mit 128 KB> Flash aus, von denen per ST-Link aber immer nur 64KB nutzbar waren. An> die obere 64KB-Hälfte kommt man nur per Bootloader dran.
Da muss man zwischen ST-Link als PC-Software und dem ST-Link als
Debugger unterscheiden. Der ST-Link Debugger hat (z.B. mit OpenOCD) kein
Problem mit den 128kb Flash, weil die Device-ID von F103C8 und F103CB
sowieso identisch ist (wie übrigens auch der Die). Die ST-Link
PC-Software liest jedoch das Flash-Size-Register aus und dort steht beim
F103C8 eben eine 64 drin, wodurch die Software dann meckert.
Für alle, die Fälschungen ganz sicher am Preis erkennen können:
Gestern sind bei mir zwei Blue Pills eingetrudelt, bestellt Anfang
Dezember zu 1,59€ das Stück inkl. Versand, beide mit Aufdruck
STM32F
103C8T6
9902Q 93
MYS 628
Serial = 0031:066d:3658:3231:4052:4307
Serial = ff56:0669:7249:4951:2614:8716
Beide verhalten sich im Greaseweazle-Test wie Originale.
Es gibt also noch "Gute" (wenn man davon absieht, dass ich bei einem der
beiden eine längere Lötorgie einlegen musste, weil 9Pins verbogen waren
und keinen Kontakt zu den Pads hatten.)
P.S.: Hm, vielleicht gibt's auch keine mehr. Ich sehe gerade, dass bei
dem Angebot nun steht: "Leider, ist dieser Artikel nicht mehr
verfügbar!"
Richard K. schrieb:> Ich habe neue "STM32-Varianten" erhalten.
Sehr schön, jetzt hat man einen Anhaltspunkt wie echte aussehen müssen,
und Beweise wenn einem eine Fälschung untergejubelt wird,
und man kann begründet Meckern wenn man betrogen wurde.
"Das hätte sich der chinesische Betrüger dann doch nicht gedacht, daß er
so derbe auffliegt".
Das aus dem Gehäuse herausholen mit deiner Methode des Backens bei 400
GradC ist auch für jeden machbar, viel einfacher als wasserfreie
Salpetersäure oder Attack Solvent.
Michael B. schrieb:> Das aus dem Gehäuse herausholen mit deiner Methode des Backens bei 400> GradC ist auch für jeden machbar, viel einfacher als wasserfreie> Salpetersäure oder Attack Solvent.
Ja das funktioniert erstaunlich gut.
Wie beschrieben kann man auch mit einem Gasbrenner (Crème Brûlée o.ä.)
arbeiten.
Beim Fotografieren hilft es natürlich enorm, wenn man schon ein bisschen
DSLR-Equipment hat. :)
...und Übung... :)
Deudschleera schrieb:> von Deudschleera
Immer wieder übel mitansehen zu müssen, wenn Bildungsversager Andere
Leute auf angebliche Fehler hinweisen wollen in dem Einzigen von dem sie
überzeugt sind dass sie es können, ihrer Muttersprache, und dabei derb
auf die Schnauze fallen.
MaWin schrieb:>> von Deudschleera> Immer wieder übel mitansehen zu müssen, wenn Bildungsversager Andere> Leute auf angebliche Fehler hinweisen wollen
Mein Deutschlehrer hätte 'Andere' klein geschrieben und Dir was von
Ironie, Zynismus und Sarkasmus erzählt...
Michael B. schrieb:> Das aus dem Gehäuse herausholen mit deiner Methode des Backens bei 400> GradC
Wo ist das beschrieben? Ich seh nur fertige Bilder, keine Beschreibung
wie er die rausgeholt hat.
Dafür musste st-flash aber zunächst ein Upgrade erhalten:
https://github.com/texane/stlink/issues/833
Die Testprogramme lassen sich über ST-Link flashen, aber die UART bleibt
tot und gibt rein gar nichts aus!
Diese Blue-Pills reagieren überhaupt nicht auf der UART und lassen auch
keine Programmierung auf dieser zu!
Kann jemand etwas zu der coreid: 2ba01477 und chipid: 410 sagen?
Es könnten CKS32F103C8T6 sein aber diese funktionieren leider nicht.
Richard K. schrieb:> https://richis-lab.de/Howto.htm>> Bitteschön...
Coole Analyse in Deinem lab ;-)
Zum Glück habe ich von verschiedenen STM32 (auch Bluepills) mit M3-Core
genug auf Lager und hatte bisher keine Aus- oder Verdachtsfälle.
Und wähne meinen Bestand mit diesen zusätzlichen Infos auf der sicheren
Seite, was gerade bei den komplexeren Chips wichtig ist.
Mit AVRs (Mega168p) aus China hatte ich vermutlich mal Pech. Daß fast
alle nicht im Originalzustand waren und mit externem Takt zwecks Zugriff
auf ISP gespeist werden mußten - geschenkt. Aber ein paar waren einfach
überhaupt nicht zum Laufen zu kriegen. Und einer funktioniert nur bei
Spannungen über 4.0V.
Die anderen funktionieren nach Augenschein so wie die alten Originale
vom Reichelt. Das sind dann zwar ca. 80% scheinbar gute, aber das
Mißtrauen bleibt. Die werden genau für die eng umrissene Funktion, die
sie ausführen sollen, umfangreich getestet (auch low power - seitig, was
ein ziemlich guter Test sein dürfte), und dann nirgends anders mehr
eingesetzt.
Es bleibt m.E. ein Spiel mit dem Feuer und ich habe keine Lust, in der
ganzen Vielfalt auch noch von einem bestimmten Prozessortyp dessen
Fake-Varianten und -Mätzchen im Kopf zu behalten. Also ich werde z.B.
CKS32-Typen niemals verwenden.
Hier ging es ebenfalls darum noch einen kleinen Bestand anzulegen.
Tja - dieses Mal hat es leider nicht geklappt.
Die Reklamation als "counterfeit product" wurde bereits problemlos zu
meinen Gunsten entschieden.
"Refund: USD 16.40 ,no need to return goods （if there is a
refund,normally buyer will receive the refund in 3-20 business days)"
Es ist jedoch immer noch nicht klar was dort eigentlich verbaut worden
ist?
Karsten M. schrieb:> Hier ging es ebenfalls darum noch einen kleinen Bestand anzulegen.> Tja - dieses Mal hat es leider nicht geklappt.>> Die Reklamation als "counterfeit product" wurde bereits problemlos zu> meinen Gunsten entschieden.> "Refund: USD 16.40 ,no need to return goods （if there is a> refund,normally buyer will receive the refund in 3-20 business days)">> Es ist jedoch immer noch nicht klar was dort eigentlich verbaut worden> ist?
Ich kann bei Bedarf einen Blick rein werfen...
Richard K. schrieb:>> Ich kann bei Bedarf einen Blick rein werfen...
Dies wäre eine Option wenn sich den Teilen keinerlei Funktion abgewinnen
lässt ...
Uwe B. schrieb:> https://www.blaatschaap.be/?p=95 zeigt, wie man die PIDR ausliest.> Nochmals die Bitte an die Besitzer von "Fakes", diese RomTable PIDr> auszulesen und zu posten!
In der Beschreibung oben ist noch ein kleiner Fehler.
Die bestückten LED's sind beide ROT - also die LED an PC13 ist hier rot
und nicht grün wie sonst üblich.
Das auslesen der ROMTable ergibt ein überraschendes Ergebnis:
1
ROMtableidentitycode3B=59
2
ROMtablecontinuationcode4=4
3
ROMtablefamily4C3=1219
4
ROMtabledesignerBB=187
Wenn man dies nachschlägt erhält man hier ARM Ltd. als Hersteller.
Dies erklärt das andere Verhalten gegenüber den üblichen Blue-Pills.
Der serielle Bootloader ist definitiv nicht enthalten, die UART's
arbeiten jedoch, wenn man über einen ST-Link ein Testprogramm flasht.
Die beiden anderen Testprogramme geben jedoch nach wie vor nichts aus
und laufen somit nicht!
Karsten M. schrieb:> Das auslesen der ROMTable ergibt ein überraschendes Ergebnis:>> ROMtable identity code 3B = 59> ROMtable continuation code 4 = 4> ROMtable family 4C3 = 1219> ROMtable designer BB = 187>>> Wenn man dies nachschlägt erhält man hier ARM Ltd. als Hersteller.
Dies bezog sich auf den "offiziellen" Jedec-Standard (siehe PDF).
ARM Ltd. bezieht sich scheinbar auf die Entwickler von ARM, die jedoch
selber keine Halbleiter herstellen, sondern diese nur lizensieren.
https://de.wikipedia.org/wiki/ARM_Limited
Dies spricht dann eher für eine absolut billige Fälschung mit
eingeschränktem Funktionsumfang?
Leider funktionieren die beiden anderen Testprogramme nicht, so daß
davon auszugehen ist das diese direkt abstürzen.
Danke - ein schöner Hinweis, aber für einen Anfänger nicht konkret
genug. ;-)
Die struct bilden die Struktur der Romtable ab, aber wie man die dann
ausliest und über das struct hübsch dekodiert ist zur Zeit leider noch
unklar ...
Wo beginnt die Romtable - bei 0xE00FF000 ?
Nachtrag:
Hier ist zumindest schon Mal die
CPUID 412FC231 h = 1093648945
Wenn man die CPIUD über das struct dekodiert erhält man
CPUID Revision 1
CPUID PartNo 3107
CPUID Architecture 15
CPUID Variant 2
CPUID Implementer 65
Und wie werden nun die einzelnen Werte weiter interpretiert?
Und das ist dann nur einer von vielen Werten:
1
// This is the ROM TABLE as defined in the Cortex-M reference manual
2
// Please note a non conforming implementation might differ from this
3
// but still be a valid ROM TABLE when being parsed as being a ROM TABLE.
4
// Meaning, this expect the entry for these components at this location
5
typedefstruct{
6
uint32_tnvic;
7
uint32_tdwt;
8
uint32_tfpb;
9
uint32_titm;
10
uint32_ttpiu;
11
uint32_tetm;
12
uint32_tend;
13
// ... ///
14
}cortex_m_romtable_t;
Durch den ganzen Dschungel blickt man einfach nicht durch ...
Wenn man Angst vor Fakes hat, kann man sich die billigen Bluepills fuer
1,5eur kaufen und bei Reichelt für 2,75eur originale Chips. Mit einem
Heissluftfön hat man innerhalb von wenigen Minuten alle Chips getauscht.
Ich denke der Preis ist immernoch vernachlässigbar und fürs hobby kommt
man ja mit einem 10er Pack Bkuepills meist ein Jahr aus.
Wie bekommt man am schnellsten das Blinky auf den Bluepill?
Ich habe auch noch einige älter sowie neue Bluepill und würde bei Fake
das ganze nem Kumpel mit nem 20k Mikroskop und um-Schleifer geben.
Schwuppse schrieb: ...
Die Arbeit kann man sich sparen wie weiter oben bereits festgestellt
worden ist und man kann sich direkt für $3.49 ein "Original" kaufen:
"Wenn man sich nicht rumärgern möchte, dann ist die vorgeschlagene
Platine von RobotDyn ein guter Kompromiß:
https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-with-arduino-bootloader.html";
Dann entfällt jedoch das spannende forschen und die Diskussion hier ...
;-)
Scheinbar kann doch über die diversen ID's sowie ein Testprogramm vieles
herausgefunden werden.
Karsten M. schrieb:> Scheinbar kann doch über die diversen ID's sowie ein Testprogramm vieles> herausgefunden werden.
einfach mal dieses Testprogramm draufspielen und schauen.. ich finde es
interessant, habe IDE und Programmer da.. das Github Projekt ist nur ein
bisschen unübersichtlich.
Nachtrag aha:
Greaseweazle includes a Blinky test firmware in the alt/ subfolder. When
written to a correct and working Blue Pill board, this firmware will
flash the PC13 LED once per second (ie. LED toggles every 500ms).
URL:https://github.com/keirf/Greaseweazle/wiki/STM32-Fakes
Philipp K. schrieb:> URL:https://github.com/keirf/Greaseweazle/wiki/STM32-Fakes
Dies ist eines der beiden Testprogramme die auf dieser Blue-Pill hängen
bleiben und nicht funktionieren!
Die bekannten CKS32-Typen laufen mit diesem Testprogramm.
Diese Blue-Pill ist was ganz anderes ...
ETM FFF42003 h = 4294189059
DWT FFF02003 h = 4293926915 (Data Watchpoint and Trace)
falls korrekt ausgelesen. Was sagt das nun aus?
Meins scheint okay zu sein.. Alles okay, nur DeviceID und Revision auf
0x000..
Ich kaufe auch gern günstig, schaue aber schon das der MCU Preis noch
mit im Board drin ist, das ist ja gesunder Menschenverstand.
dieses Testprogramm ist ja interessant. verstehe ich das richtig, dass
wenn das Programm nicht blinkt ein Fake vorliegt und wenn es blinkt
alles ok ist?
O.K. Danke.
Die Ausgabe ist ein interessantes Konzept mit der Kennung dead:beef
Allerdings funktioniert auch dieses Testprogramm nicht auf dieser
Blue-Pill!
Es führt nur zu Fehlermeldungen auf dem USB-Bus:
Selbstverständlich ist auch auf dieser Blue-Pill R10 falsch bestückt,
aber dieser wurde bereits korrigiert.
Daher habe ich mein letztes Test-Programm für die Ausgabe auf dem
USB-Bus kompiliert, um zu überprüfen ob dieser überhaupt funktioniert.
Das Ergebnis ist positiv!
Das Programm stelle ich als HEX-File zur Verfügung.
Obwohl es sehr primitiv ist, kann damit eigentlich schon eine ganze
Menge überprüft werden:
* Blink-Test als Anzeige für die Ausführung
* Test des AD-Wandlers
* Ausgabe des internen Temperatur-Sensors
* Test der USB-Schnittstelle
* Ausgabe und Interpretation einer Reihe von ID's
Das USB-Device wird folgendermaßen erkannt:
Kurzer hinweis:
Das Testprogramm führte dazu, dass ich mein Bluepill nicht mehr
programmieren konnte. Scheinbar wird die SWD-Schnittstelle blockiert.
Man kann allerdings durch Gedrückthalten der RESET-Taste per ST-Link
wieder programmieren.
Nur damit sich niemand wundert, wenn es danach scheinbar nicht mehr
geht...
Das ist wirklich verrückt!
Ich habe nun direkt noch einmal das STM32F103C8-DIAGNOSTICS.bin geflasht
und dies ging nicht nur ohne Probleme, sondern dieses Mal funktioniert
es auch:
stm32id
Die xy coords: 33688871
Wafer Number: 50
Lot_num ascii encoded [23:0]: 0x00534312 | S C .
Lot_num ascii encoded [55:24]: 0x004E4B35 | . N K 5
Die MCU hat definitiv nur 64 KB Flash und nicht 128 KB wie die anderen
Blue-Pills.
Das Blinky_Test-v0.11.hex läuft nach wie vor nicht!
Gibt es irgendeine Erklärung für dieses merkwürdige Verhalten?
Mein Testprogramm ist übrigens mit STM32Duino kompiliert.
Mike J. schrieb:> Kannst du das mal mit der hier aufgeführten Testmethode probieren?> STM32F103C8T6 STM32 Billig Board>> https://www.mikrocontroller.net/articles/STM32F103C8T6_STM32_Billig_Board#128k_Flash
Mit openocd habe ich bislang noch nicht gearbeitet.
Die Vielfalt an Tools für die STM32-Controller ist ebenfalls so ein
Thema ...
Die Datei konnte ich noch editieren, aber es funktioniert nicht, weil
die board.cfg fehlt ?
(So eine Datei gibt es nirgendwo im Pfad /usr/share/openocd)
(Zumindest bei Installation von openocd über den Paketmanager.)
Karsten M. schrieb:> Die Datei konnte ich noch editieren, aber es funktioniert nicht, weil> die board.cfg fehlt ?> (So eine Datei gibt es nirgendwo im Pfad /usr/share/openocd)> (Zumindest bei Installation von openocd über den Paketmanager.)
Ist im Anhang.
Nutze aber besser die in der Artikel-Seite beschriebene board.cfg ...
einfach mal runter scrollen.
Ist das Debian 8 zu alt?
Ich könnte es noch unter Debian 10 testen, aber bringt das was?
Hier wird die Blue-Pill scheinbar als Flash-Speicher für ein Bild
missbraucht.
Das ist natürlich witzig, aber auch nicht anders als wenn mit Forth
einfach der Speicherbereich voll geschrieben wird und wieder ausgelesen.
Interessanter wäre eine Erklärung der ganzen ominösen Seiteneffekte beim
programmieren der Blue-Pill, sowie eine Interpretation der ganzen
ausgelesenen Informationen?
Karsten M. schrieb:> Error: Debug adapter doesn't support 'swd' transport
Kannst du es noch ein mal mit der hier probieren?
Kann sein dass ich die falsche Datei erwischt hatte.
Das Bild im Flash dient ja nur der einfachen Veranschaulichung.
Mike J. schrieb:> Kannst du es noch ein mal mit der hier probieren?
Kein Problem.
> Das Bild im Flash dient ja nur der einfachen Veranschaulichung.
Daher ist es auch witzig.
Könnte natürlich ein noch witzigeres Bild sein.
Danke Ungläubiger, gut dass das auch mal erwähnt wird.
Wir verkaufen seit 2+ Jahren Blue Pills und nun auch ganz neu die
STM32F411 module hauptsächlich in Kanada und US, und wir hatten auch CSK
Chips auf den Blue Pills vor etwa einem Jahr, wussten gar nicht dass es
diese gibt, bevor uns ein Kunde darauf aufmerksam gemacht hat.
Es ist Tatsache, dass viele von den Chinesischen Händlern die
Unterschiede gar nicht kennen, und auch nicht in der Lage sind Original
und Fälschung zu unterscheiden. Und dann gibt es die anderen, die uns
ganz offiziell CS32 chips anbieten, mit fake STM32 print, und hoffen
dass wir darauf fliegen weil man ja damit viel mehr Geld machen kann als
mit den original STM32 chips, die ja "viel zu teuer" sind.
Immer wenn wir eine grosse Ladung einkaufen lassen wir uns einige Muster
vorab schicken, und dann erst bestellen wir grössere Mengen aus der
selben Produkt. Seit wir das machen können wir ziemlich sicher sein, nur
original STM32 chips auf unseren Modulen zu haben (und natürlich den
korrekten 1k5 USB Widerstand).
Aber zurück zu Ungläubiger's Beitrag: Unsere Kunden hier haben begriffen
dass der direkte Einkauf in China spart 2 oder 3 Dollar, birgt aber
grosse Risiken. Wir minimieren das Risiko, aber müssen halt mehr
verlangen als der durchschnittliche Aliexpress Home-Dekor & Dessous
Verkäufer, der nebenbei auch noch Blue Pills und Raspberry Pi Gehäuse
anbietet. Und wenn mal etwas nicht okay ist, erstatten wir auch den
Kaufpreis oder liefern Ersatz innerhalb von 3 tagen, anstatt 3 Monaten.
universal-solder.ca
Hallo Universal-Solderer,
eure Preise sind auch sehr fair. Wenn man aber die Wahl hat zwischen 2€
und 20€ pro Stück, dann kann man schon auf die Idee kommen direkt in
China zu bestellen. Bei euren 20CAD für 3x BluePill + ST/Link-Clone,
oder 13€, würde ich das nicht tun. Leider verschickt ihr nicht nach DE.
Es ist schön das sich hier ein Profi zu Wort meldet.
Hoffentlich nicht nur um Eigenwerbung zu machen.
Wilfried Volker Forster schrieb:> Es ist Tatsache, dass viele von den Chinesischen Händlern die> Unterschiede gar nicht kennen.
Manche Händler scheinen keinen Schimmer zu haben was sie da eigentlich
verkaufen.
Dies dürfte aber für viele Händler gelten die gemischte Waren anbieten.
Angesichts des großen Produkt-Sortiments scheinen viele Händler die
Produkte gar nicht in einem eigenen Lager zu haben, sondern verkaufen
nur in Komission?
> Immer wenn wir eine grosse Ladung einkaufen lassen wir uns einige Muster> vorab schicken, und dann erst bestellen wir grössere Mengen aus der> selben Produkt. Seit wir das machen können wir ziemlich sicher sein, nur> original STM32 chips auf unseren Modulen zu haben (und natürlich den> korrekten 1k5 USB Widerstand).
Leider nur ziemlich sicher ?
Dies spricht dafür das keine Neuware oder zumindest Restposten von den
Herstellern verbaut werden, die sich permanent ändern.
Die interessanteste Information ist daher ob Ihr direkt mit einem der
Hersteller verhandelt?
Wie habt Ihr die dazu gebracht sogar korrekte Bestückungen
durchzuführen?
Oder ist es nur so das zumindest einige wenige verstanden haben das man
mit Qualität einfach mehr Geld verdienen kann?
Vielleicht wird ja alles attraktiver wenn man gleichzeitig Dessous
anbietet? :-)
> Vielleicht wird ja alles attraktiver wenn man gleichzeitig Dessous> anbietet? :-)
oder Dessous mit Bluepill-Aufdruck ^^
PS: finde es auch ganz gut, wenn Lieferanten bewusst auf originale Ware
achten. Klar - der Preis ist jetzt nicht so niedrig, aber insbesondere
bei kleinen Stückzahlen sollte das gar keine Rolle spielen. Zumal man
sich eine Menge Ärger spart...
Ich hatte hiervon auch 10 gekauft:
https://www.ebay.de/itm/Minimum-System-Development-Board-STM32F103C8T6-STM32-Module-For-Arduino/274025677680?hash=item3fcd340370:g:3asAAOSwZc1djF6u
Geliefert wurden CKS32F103 wie im Bild. Natürlich habe ich das erst mal
reklamiert, und das Angebot vom Verkäufer angenommen, den halben Preis
zu erstatten. Die oben irgendwo getroffene Aussage, dass Open-Drain
nicht funktioniert, kann ich so nicht bestätigen. Jedenfalls bei den
Pins die ich probiert habe. Auch sonst konnte ich bisher keine Probleme
erkennen. Auf alle Fälle ist die Situation unbefriedigend, wenn man
immer die Katze im Sack kauft, allerdings für knapp 80Cent pro Stück
kann man die Dinger immer noch für viele Sachen gebrauchen. Und wenn mal
was nicht geht ist ein Tausch zum Probieren schnell gemacht.
Man kann diese Quellen natürlich auch zum Eindecken mit preiswerter
Bastelware verwenden. Je mehr und je häufiger da welche reklamieren,
desto schneller sollten die Händler lernen die Ware richtig zu
deklarieren.
Nachtrag:
Entweder ich bin zu blöd oder habe Tomaten auf den Augen. Nachdem mir
der Verkäufer über eBay den halben Preis erstattet hat, ist der Artikel
aus meiner Liste der eBay Käufe verschwunden und damit ist auch die
Möglichkeit weg, die Transaktion zu bewerten. Da braucht man sich nicht
wundern, wenn es keine negativen Bewertungen bezüglich dieses Problems
gibt.
Ist schon frech, das Ding als "STM32F103C8T6 STM32 Module For Arduino"
zu bezeichnen, ein Foto, wo ein echter ST Chip drauf ist, daneben zu
setzen und dann CKS32 zu liefern.
Allerdings muss man bei 1,58 Euro/Stck. einfach stutzig werden.
Matthias S. schrieb:> Allerdings muss man bei 1,58 Euro/Stck. einfach stutzig werden.
Da ist was dran. Das blöde ist nur, selbst beim doppelten Preis kann man
nicht mehr sicher sein. Die deutschen Durchreicher nehmen zwischen 4 und
5€, ob da das Original garantiert ist?
Am sichersten scheint mir aktuell die robotdyn-Variante für knapp 3$. Da
hat man als Mehrwert eine schmalere Bauform und bessere Qualität. Und
man bekommt auch eine STM32F303 Variante in der gleichen Bauform.
Interessant ist auch das hier:
https://robotdyn.com/black-pill-apm32f103cb-128kb-flash-20kb-sram-stm32-compatible-arm-cortexr-m3-mcu-mini-board.html
Jedenfalls vom Preis und den Extras wie FPU und CAN/USB gleichzeitig.
Kennt die schon jemand? Keils MDK5 hat die jedenfalls in der Liste.
Matthias S. schrieb:> Allerdings muss man bei 1,58 Euro/Stck. einfach stutzig werden.
Eigentlich nicht, denn zu dem Preis gab es mehrere Jahre lang BluePills
mit ausschließlich originalen STM32-Controllern, das Problem mit den
Fälschungen kam ja erst vor einigen Monaten auf.
temp schrieb:> Am sichersten scheint mir aktuell die robotdyn-Variante für knapp 3$. Da> hat man als Mehrwert eine schmalere Bauform und bessere Qualität. Und> man bekommt auch eine STM32F303 Variante in der gleichen Bauform.
In die Richtung tendiere ich auch.
Karsten M. schrieb:> Hat schon jemand Erfahrungen mit der Unterstützung durch die FPU> gemacht?> (Unterstützung durch den Compiler, Geschwindigkeitsgewinn)
Na sicher, das wird man beim typischen Arduino-LED-Blink Programm auch
sicher merken.
temp schrieb:> Ich hatte hiervon auch 10 gekauft:>> https://www.ebay.de/itm/Minimum-System-Development-Board-STM32F103C8T6-STM32-Module-For-Arduino/274025677680?hash=item3fcd340370:g:3asAAOSwZc1djF6u>> Geliefert wurden CKS32F103 wie im Bild.
Ging mir jetzt auch so, zum ähnlichen Preis. Aber das ist mein
Lieblingshändler modul_technik, der hat bisher immer korrekt und sehr
schnell zu guten Preisen geliefert. Ich habe nicht schlecht bewertet
oder reklamiert, weil ich das schon erwartet habe. Anschreiben werde ich
ihn trotzdem und darauf hinweisen.
R. M. schrieb:> das Problem mit den> Fälschungen kam ja erst vor einigen Monaten auf.
Der CKS32F103 ist kein dysfunktionales fake, sondern ein gar nicht mal
so schlechter Prozessor.
Cyblord -. schrieb:> Karsten M. schrieb:>> Hat schon jemand Erfahrungen mit der Unterstützung durch die FPU>> gemacht?>> (Unterstützung durch den Compiler, Geschwindigkeitsgewinn)>> Na sicher, das wird man beim typischen Arduino-LED-Blink Programm auch> sicher merken.
Aber nur wenn die Wartezeit mit Fließkomma berechnet wird. ;-)
Dann kann die LED besser für Bruchteile von Sekunden blinken ...
Falls jemand einen Bluepill mit nicht STM32 uebrig hat, nehme ich ihn
gerne um den Prozessor in BMP aufzunehmen. Mailadresse und ggf
Kostenvorstellung per Mail.
Die BlackPill von RobotDyn gibt es wahlweise mit STM32F103 (M3) oder mit
STM32F303 (M4). Karsten hatte die Variante mit F103 verlinkt aber
offensichtlich die mit F303 gemeint.
Aber wir kommen vom eigentlichen Thema dieses Threads ab...
Carl D. schrieb:> Die Doku ist nicht vielversprechend. Die FPU scheint kein Bestandteil> des ARM zu sein (dazu bräuchte es vermutlich M4). Zudem gibt es einen> Io-Bereich namens FPU, also eher ein FP-Device. Nix mit> schnell/Compiler-Unterstützung.
Was für einen Sinn soll dann die angebliche FPU haben, wenn diese nicht
Teil des Prozessors ist?
Werden dann die float-Werte und die gewünschte Operation in IO-Adressen
geschrieben und nachfolgend wird dann auf wundersame Art und Weise ein
Ergebnis über weitere IO-Adressen geliefert?
Dann kann die FPU auch direkt komplett extern sein. :-)
Gibt es inzwischen vielleicht schon eine FPU über SPI oder I2C?
R. M. schrieb:> Die BlackPill von RobotDyn gibt es wahlweise mit STM32F103 (M3) oder mit> STM32F303 (M4). Karsten hatte die Variante mit F103 verlinkt aber> offensichtlich die mit F303 gemeint.>> Aber wir kommen vom eigentlichen Thema dieses Threads ab...
Es ging um den auf BlackPill auch bestückten APM32F103CB, der eben auch
kein echter STM32 ist.
R. M. schrieb:> Die BlackPill von RobotDyn gibt es wahlweise mit STM32F103 (M3) oder mit> STM32F303 (M4). Karsten hatte die Variante mit F103 verlinkt aber> offensichtlich die mit F303 gemeint.
Ähm - keine Ahnung - hier ist von einer APM32F103CB die Rede.
Hat jemand ein Datenblatt für so etwas gefunden?
> Aber wir kommen vom eigentlichen Thema dieses Threads ab...
Nur teilweise, denn es geht hier u.a. um die verschiedenen MCU-Varianten
die als Pillen verkauft werden.
Übrigens auch über Aliexpress vermarktet:
https://www.aliexpress.com/item/32802556794.html
Karsten M. schrieb:> Carl D. schrieb:>> Die Doku ist nicht vielversprechend. Die FPU scheint kein Bestandteil>> des ARM zu sein (dazu bräuchte es vermutlich M4). Zudem gibt es einen>> Io-Bereich namens FPU, also eher ein FP-Device. Nix mit>> schnell/Compiler-Unterstützung.>> Was für einen Sinn soll dann die angebliche FPU haben, wenn diese nicht> Teil des Prozessors ist?>> Werden dann die float-Werte und die gewünschte Operation in IO-Adressen> geschrieben und nachfolgend wird dann auf wundersame Art und Weise ein> Ergebnis über weitere IO-Adressen geliefert?>> Dann kann die FPU auch direkt komplett extern sein. :-)> Gibt es inzwischen vielleicht schon eine FPU über SPI oder I2C?
So hat man das schon in den 70ern bei 8080 gemacht, da gab's einen
Baustein der genau so funktionierte. Operanden und Opreator rein,
Ergebnis (viel später) wieder raus. Aber FPU ist werbewirksam und eine
ARM-Lizenz für M4F statt M3 teuer.
Carl D. schrieb:> Es ging um den auf BlackPill auch bestückten APM32F103CB, der eben auch> kein echter STM32 ist.
Asche auf mein Haupt! Das Detail hatte ich übersehen und mir waren die
BlackPills bisher nur mit originalen F103 und F303 geläufig.
Carl D. schrieb:> So hat man das schon in den 70ern bei 8080 gemacht, da gab's einen> Baustein der genau so funktionierte.
Ja genau - eine 8087 zum einstecken.
> Operanden und Opreator rein,> Ergebnis (viel später) wieder raus. Aber FPU ist werbewirksam und eine> ARM-Lizenz für M4F statt M3 teuer.
Also das ist wirklich krank!
Ob sich der Entwicklungs- und Produktionsaufwand für so einen Unsinn
lohnt?
Wenn man aus Spaß Mal in die Library und das SDK hineinschaut,
https://www.apexmic.com/uploads/tool/APM32F10x_StdPeriph_Lib_V1.0.0.ziphttps://www.apexmic.com/uploads/tool/APM32F103_SDK_V1.0.0.rar
dann gibt es noch nicht einmal ein gültiges Beispiel oder irgendeine
Beschreibung wofür diese FPU überhaupt gut sein soll.
Also wird völlig ohne Sinn einfach irgendein Modul drangeflanscht,
dessen Funktion noch nicht einmal beschrieben ist?
Karsten M. schrieb:> Ob sich der Entwicklungs- und Produktionsaufwand> für so einen Unsinn lohnt?
Offensichtlich wurde der Aufwand betrieben, also - warum nicht? Wir
haben vor ein paar Jahren auch an Acceleratoren rumgeforscht (allerdings
mit FPGAs).
Karsten M. schrieb:> Also wird völlig ohne Sinn einfach irgendein Modul drangeflanscht,> dessen Funktion noch nicht einmal beschrieben ist?
Niemand hat gesagt, dass die Funktion nicht beschrieben ist. Ich hab
seit einiger Zeit mit Chipsätzen zu tun, bei denen die Funktion durchaus
gut beschrieben ist - aber nicht für mich.
Warum sollten andere das nicht auch können?
Oder nochmal anders: So einen Chip entwickelt man nicht aus Spaß heraus
und fertigt in Serie. Da hat man schonmal mindestens einen Großabnehmer
an der Hand, und wenn der so eine Funktion wünscht, dann baut man die
halt ein.
Karsten M. schrieb:> Carl D. schrieb:>> So hat man das schon in den 70ern bei 8080 gemacht, da gab's einen>> Baustein der genau so funktionierte.>> Ja genau - eine 8087 zum einstecken.
Nein, der lief immer parallel zum 8086 und hat alle Befehle mitgehört.
Wenn es FP war, dann hat der 86er pausiert und der 87er übernommen. Nur
wenn Speicher zu lesen/schreiben gab, dann hat der 86er die Adressen
bereitgestellt und der 87er Daten gelesen/geliefert. Da gab es extra
Pins an beiden, das interne Prefetch zu synchronisieren, damit beide die
gleichen Befehle "sehen". Die beiden könnten sogar parallel arbeiten,
wenn mal ein FP-Befehl keinen Mem-Zugriff brauchte. Wenn man dann ein
Rechenergebnis vom 87er brauchte, dann müßte man im Programm per FWAIT
warten, bis der teuere Nachbar soweit war. Damit war FP locker 10x
schneller. Für ein Studentenmonatsgehalt.
Zurück zum ADM32: vermutlich die billigste (und nutzloseste) Art FP
dranschreiben zu dürfen. Bestimmt nur SP, was für den M3 auch in
Software kein großes Problem sein sollte.
S. R. schrieb:> Oder nochmal anders: So einen Chip entwickelt man nicht aus Spaß heraus> und fertigt in Serie. Da hat man schonmal mindestens einen Großabnehmer> an der Hand, und wenn der so eine Funktion wünscht, dann baut man die> halt ein.
Das Argument ist einleuchtend.
Werden dann in der Regel solche "kundenspezifischen Chips" nicht
exklusiv gefertigt und nicht allgemein verkauft?
Immerhin machen sie ja mit der FPU "Werbung" ohne diese zu
dokumentieren.
Es sei denn die Dokumentation erfolgt noch, denn das Produkt scheint neu
von Dez. 2019.
Karsten M. schrieb:> Werden dann in der Regel solche "kundenspezifischen Chips" nicht> exklusiv gefertigt und nicht allgemein verkauft?
Warum exklusiv verkaufen? Wenn der Kunde das so will, dann sicherlich.
Aber ich kann ein Produkt mit einem bestimmten Kunden im Hinterkopf
entwickeln und trotzdem auf dem freien Markt anbieten. Vielleicht mit
Vorzugskonditionen oder so...
Karsten M. schrieb:> Immerhin machen sie ja mit der FPU "Werbung" ohne diese zu> dokumentieren.
Zumindest ein "Product Brief" liegt meist öffentlich rum, und da wäre es
schon sehr seltsam, wenn in manchen Dokumenten die FPU erwähnt wird und
in anderen nicht. Ich denke mal, bei sowas geht es darum, den Aufwand
gering und die Konsistenz hoch zu halten.
> Es sei denn die Dokumentation erfolgt noch, denn> das Produkt scheint neu von Dez. 2019.
Das kann natürlich auch sein. Oder es ist eine der Vorzugskondition,
dass der Wunschkunde die Dokumentation ein paar Monate früher bekommt...
S. R. schrieb:
...
Wenn dem so ist, warum dann eine FPU implementieren und danach nicht
dokumentieren wie diese verwendet werden kann?
Dies widerspricht einer sinnvollen Vermarktungs-Strategie.
Karsten M. schrieb:> S. R. schrieb:> ...>> Wenn dem so ist, warum dann eine FPU implementieren und danach nicht> dokumentieren wie diese verwendet werden kann?> Dies widerspricht einer sinnvollen Vermarktungs-Strategie.
Was soll da drin stehen?
"Achtung die FPU ist nur ein Arithmetik-Device a la Siemens80517"
Wenn man das nicht genau beschreibt, dann bleibt der Werbeeffekt länger
bestehen.
Diese spezielle Peripherie gibt es wahrscheinlich günstig als IP, so wie
auch der Rest der STM32F103-Kompatibilität kaufbar ist. Wäre STM
aleiniger Besitzer dieses IP, dann gäbe es nicht so viele Clones (z.B.
auch als RiscV).
Hallo Leute,
ich habe mal wieder ein kleineres Update zur "Hardware" der
STM32-Varianten.
Vielleicht wissen es die meisten schon, dennoch ist die Erkenntnis des
heutigen Tages, dass der CKS32F103C8T6 und der CKS32F103C8T6 die
gleichen Dies enthalten:
https://www.richis-lab.de/STM32_03.htm
Zugegebenermaßen war das zu erwarten, aber Kontrolle ist besser. :)
Außerdem hatte ich noch einen CKS32F103CBT6 (B, nicht 8), der ebenfalls
auf dem gleichen Die basiert.
Viele Grüße,
Richard
Richard K. schrieb:> Vielleicht wissen es die meisten schon, dennoch ist die Erkenntnis des> heutigen Tages, dass der CKS32F103C8T6 und der CKS32F103C8T6 die> gleichen Dies enthalten:
Ich musste jetzt dreimal hinschauen, aber ich sehe keinen Unterschied
zwischen CKS32F103C8T6 und CKS32F103C8T6 ;-)
Du meinst wohl: CKS32F103C8T6 und CS32F103C8T6 (ohne K)....
Frank M. schrieb:> Richard K. schrieb:>> Vielleicht wissen es die meisten schon, dennoch ist die Erkenntnis des>> heutigen Tages, dass der CKS32F103C8T6 und der CKS32F103C8T6 die>> gleichen Dies enthalten:>> Ich musste jetzt dreimal hinschauen, aber ich sehe keinen Unterschied> zwischen CKS32F103C8T6 und CKS32F103C8T6 ;-)>> Du meinst wohl: CKS32F103C8T6 und CS32F103C8T6 (ohne K)....
Mist, genau so war es gemeint. Mit diesen länglichen Bezeichnungen kann
man aber auch nur stolpern...
Karsten M. schrieb:> Wenn dem so ist, warum dann eine FPU implementieren und> danach nicht dokumentieren wie diese verwendet werden kann?
Wie ich bereits schrieb: Es ist sehr wahrscheinlich, dass die FPU
vollkommen ausreichend dokumentiert ist - nur nicht für uns.
Karsten M. schrieb:> Dies widerspricht einer sinnvollen Vermarktungs-Strategie.
Warum? Beispiel: Ich entwickle einen Chip für $GROẞKUNDE, mit
Vorzugskonditionen, aber nicht exklusiv.
Wie sorge ich dafür, dass (a) der Kunde bevorzugt beliefert wird; (b)
ich nicht mit Anfragen von Drittkunden überrannt werde; (c) ich
möglicherweise schlechte Presse "Lieferschwierigkeiten! Vaporware!"
bekomme?
Ganz einfach: Ich lasse einen wichtigen Teil öffentlich unspezifiziert
(und halte damit das Interesse niedrig), bis ich meine Lieferkette und
Logistik im Griff habe und $GROẞKUNDE zufrieden ist. Dann schiebe ich
die Dokumentation nach.
Es kann natürlich auch sein, dass die IP nur zugeklaut ist.
Dokumentation gibt's nur unter der Hand und wenn das Produkt genug
Interesse generiert hat, wird lizenziert. Spart Lizenzgebühren für
Totgeburten und Einmalwunder...
S. R. schrieb:
...
Ja - diese Strategie ist nachvollziehbar.
Allerdings hat diese den Nachteil das - wie hier gerade festgestellt -
eine APM32F103 keine benutzbare FPU für den allgemeinen Markt hat.
Diese Feststellung muß dann später von dem Hersteller ausgeräumt werden,
falls es doch noch eine Dokumentation gibt und die Erweiterung wirklich
lohnenswerte Vorteile bringt.
Chinesische Denkweise ...
Karsten M. schrieb:> Chinesische Denkweise ...
Nö, definitiv nicht nur chinesisch. Informationen auf "need to
know"-Basis findet man überall, wo es um Geld geht.
S. R. schrieb:> Nö, definitiv nicht nur chinesisch. Informationen auf "need to> know"-Basis findet man überall, wo es um Geld geht.
Wenn eine Funktion unter
https://www.apexmic.com/en/newproduct/apm2/16
System & Architecture
ARM®Cortex®-M3
Frequency 72MHz
Built-in AHB and APB
Support FPU
angepriesen wird und weder dokumentiert noch nutzbar ist, hat dies
definitiv nichts mit "need to know" zu tun, sondern kann unter
Fake-Funktion verbucht werden.
Dann haben so ziemlich alle Qualcomm-Chipsets ausschließlich
"Fake-Funktionen". Zumal ich behaupte, dass die Funktion durchaus
nutzbar ist - nur eben nicht für dich.
Du bist halt nicht der Nabel der Welt. :-)
S. R. schrieb:> Du bist halt nicht der Nabel der Welt. :-)
Habe ich das behauptet?
Ich nehme mir lediglich das Recht heraus enttäuscht darüber zu sein, daß
Produktversprechen nicht eingelöst werden.
Jeder muß unterstützen was er für richtig hält. ;-)
Könnte es sich dabei nicht einfach um die ARM Standard FPU handeln und
daher wird auf die Doku verzichtet?
Selbst das Aktivieren der FPU findet ja im Cortex internal peripherals
register set statt.
Mw E. schrieb:> Könnte es sich dabei nicht einfach um die ARM Standard FPU handeln und> daher wird auf die Doku verzichtet?> Selbst das Aktivieren der FPU findet ja im Cortex internal peripherals> register set statt.
Nicht wenn die Angabe "Cortex M3" richtig ist. FPU gibt es optional ab
M4.
Carl D. schrieb:> Nicht wenn die Angabe "Cortex M3" richtig ist. FPU gibt es optional ab> M4.
Ich weis ;)
Aber bei den Chinesen weis man ja nicht so was die da gefummelt haben.
Es wäre doch höchst umständlich wenn man alle float Funktionn im
Programm so umschreiben müsste, dass diese eine am AHB/APB hängende FPU
nutzen anstatt eine integrierte.
Mw E. schrieb:> Könnte es sich dabei nicht einfach um die ARM Standard FPU handeln und> daher wird auf die Doku verzichtet?
In der spärlichen Dokumentation ist explizit eine FPU nach IEEE 754
Standard erwähnt.
https://de.wikipedia.org/wiki/IEEE_754#Operationen
Es wäre nicht überraschend, wenn einfach diese verwendet worden ist:
https://opencores.org/projects/fpu
Wenn man nach den chinesischen Versionen der Dokumentation schaut
https://www.apexmic.com/cn/newproduct/apm2/16
findet man ein Update vom 27.3.2020, welches jedoch keine neueren
Details offenbart.
Da es jedoch einen überarbeiteten "Apexmic model guide" gibt, ist die
Entwicklung scheinbar noch im Gange und es ist vielleicht doch noch eine
bessere Dokumentation zu erwarten ...
Hallo,
frei nach dem Motto "Wenns dem Esel zu wohl wird, geht er aufs Eis"
wollte ich mich nach jahrelanger Anwendung von 8-bit Atmels mit den
STM32 beschäftigen, just for fun und um nicht einzurosten. Dazu habe ich
u.a. das PDF-Buch von Stefan ⛄ F. (Danke Stefan) durchgearbeitet. Hat
auch soweit alles funktioniert und dann bin ich auf diesen Thread
gestoßen. Ich war natürlich neugierig, ob ich hier auch Fakes auf meinen
BluePills habe.
Ergebnis vom Binky-Test:
** Blinky Test **
** Keir Fraser <keir.xen@gmail.com
** https://github.com/keirf/Greaseweazle
Serial = 1324:0104:122d:4d38:4b43:004e
Flash Size = 128kB
Device ID = 0x0410
Revision = 0x2003
**WARNING**: 10xx8/B device returned valid IDCODE! Fake?
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop)
Hier habe ich auch ein Bild gefunden, https://richis-lab.de/STM32_04.htm
dessen Beschriftung genau dem STM32 auf meinem BluePills entspricht,
also schließe ich auf Fakes. Da bisher aber alles funktioniert werde ich
erst mal damit weiter machen.
Reinhard
Ich dupliziere den Text aus dem APM32-Thread mal hier rein, da er im
Rahmen von STM32-Fälschungen auch interessant werden könnte:
Ich habe Bilder des APM32-Dies gemacht:
https://www.richis-lab.de/STM32_05.htm
Der Chip scheint zumindest zu einem gewissen Teil von SEC-CHIP
entwickelt worden zu sein.
Außerdem erinnert das Die entfernt an den CKS32/CS32:
https://www.richis-lab.de/STM32_03.htm
Diese Testpads innerhalb der Logik...
So, hier habe ich noch einen GD32 für euch:
https://www.richis-lab.de/STM32_06.htm
Auch das ist nicht der STM32-Clon, der sich in der hier ursprünglich
diskutierten ST-Fälschung befunden hat.
Richard K. schrieb:> So, hier habe ich noch einen GD32 für euch:>> https://www.richis-lab.de/STM32_06.htm
Schick, danke dafür.
Ein GD32VF103 wäre im Vergleich noch ganz nett, ich habe leider nur
keinen den ich Dir dafür schicken könnte.
"Auf einem großen Die, das die meisten Funktionsblöcke des
Mikrocontrollers enthält, befindet sich der Flash-Speicher."
Das SRAM, der Arbeitsspeicher.
Rudolph R. schrieb:> Richard K. schrieb:>> So, hier habe ich noch einen GD32 für euch:>>>> https://www.richis-lab.de/STM32_06.htm>> Schick, danke dafür.> Ein GD32VF103 wäre im Vergleich noch ganz nett, ich habe leider nur> keinen den ich Dir dafür schicken könnte.>> "Auf einem großen Die, das die meisten Funktionsblöcke des> Mikrocontrollers enthält, befindet sich der Flash-Speicher.">> Das SRAM, der Arbeitsspeicher.
Gerne! Hat mich keine große Überwindung gekostet. :)
Bezüglich dem GD32VF103 kann ich ja mal meine Augen offen halten...
Die Beschreibung ist vielleicht etwas unglücklich gewählt. Gemeint ist:
Oberhalb des großen Dies befindet sich auf dem kleinere Die der
Flash-Speicher.
Das muss ich noch umformulieren...
Richard K. schrieb:> Bezüglich dem GD32VF103 kann ich ja mal meine Augen offen halten...
Ich könnte dir einige GD32VF103CBT6 schicken. Wenn ich dir die andere
Chips geschickt hatte, hatte ich die GD32VF Chips noch nicht.
(GromBeestje @ EEVBlog / blaatschaap.be )
Und noch der BLM32F103CBT6:
https://richis-lab.de/STM32_08.htm
Bis jetzt war noch nicht der Controller dabei, der sich in dem
gefälschten STM32 dieses Threads befunden hat...
Dank André haben wir nun auch den STM32-Clon, der sich in der Fälschung
befand, mit dem dieser Thread gestartet wurde! Es handelt sich um einen
Hangshun HK32:
https://www.richis-lab.de/STM32_09.htm
Richard K. schrieb:> Und noch der BLM32F103CBT6:>> https://richis-lab.de/STM32_08.htm
Danke daß Du die Übersicht auf Deiner Webseite führst, bei den vielen
Klonen kann man schnell mal den Überblick verlieren...
Mir ist auf Deiner Seite https://www.richis-lab.de/STM32.htm
aufgefallen, daß der BLM32 falsch verlinkt zu sein scheint. Er zeigt auf
..._05 statt auf ..._08.
Gerd E. schrieb:> Richard K. schrieb:>> Und noch der BLM32F103CBT6:>>>> https://richis-lab.de/STM32_08.htm>> Danke daß Du die Übersicht auf Deiner Webseite führst, bei den vielen> Klonen kann man schnell mal den Überblick verlieren...>> Mir ist auf Deiner Seite https://www.richis-lab.de/STM32.htm> aufgefallen, daß der BLM32 falsch verlinkt zu sein scheint. Er zeigt auf> ..._05 statt auf ..._08.
Danke für den Hinweis, hab ich korrigiert!
Und danke für eure lobenden Worte!
Karsten W. schrieb:
Es ist noch eine neue Variante mit dem gleichen Chip mit Code 3B
angekommen.
Eine richtige Fälschung mit eingravierten Bezeichnungen von ST.
Die Blue-Pill hat eine rote und grüne LED bestückt und R10 hat sogar den
richtigen Widerstandswert von 1K5.
1
DWT(DataWatchpointandTrace)FFF02003h=4293926915
2
ETMFFF42003h=4294189059
3
CPUID412FC231h=1093648945
4
CPUIDRevision1h=1
5
CPUIDPartNoC23h=3107
6
CPUIDArchitectureFh=15
7
CPUIDVariant2h=2
8
CPUIDImplementer41h=65
9
ROMtableidentitycode3Bh=59
10
Hersteller:ARMLtd.
11
ROMtablecontinuationcode4h=4
12
ROMtablefamily4C3h=1219
13
ROMtabledesignerBBh=187
Dieses Mal hat der Chip jedoch 128 KB Speicher.
Das Testprogramm Greaseweazle funktioniert darauf nicht.
1
istm32id
2
Diexycoords:16871067
3
WaferNumber:16
4
Lot_numasciiencoded[23:0]:0x00534713|SG.
5
Lot_numasciiencoded[55:24]:0x004E4C38|.NL8
6
7
Testing64kBFlashblock:0x10000-0x1FFFF
8
Erasing
9
Flashwith1010101010101010(0xAA)
10
Testingfor0xAA-OK
11
Erasing
12
Flashwith0101010101010101(0x55)
13
Testingfor0x55-OK
14
Erasing
15
~~~~~ALLTESTSPASSED~~~~~
Fazit:
Blue-Pills wo ein Original STM32F103 bestückt ist sind scheinbar selten
geworden.
Da sollte man besser eine Black Pill von RobotDyn bestellen.
Wenn es kein Original sein muß, dann besser direkt einen CKS32F103C8T6
bestellen.
Karsten W. schrieb:> Blue-Pills wo ein Original STM32F103 bestückt ist sind scheinbar selten> geworden.
Machst du die Verkäufer darauf auch aufmerksam und forderst dein Geld
zurück?
Wenn die Verkäufer ihr eigenes Verhalten irgend einen Plunder zu
verkaufen entweder nicht erkennen oder gut damit weg kommen, dann machen
sie es immer weiter.
Die überlegen sich erst dann ob diese Masche sich lohnt, wenn sie
dadurch Nachteile erleiden. (also wenn sie es am Geldbeutel merken)
Neue eBay-Verkäuferaccounts können sie ja innerhalb von wenigen Minuten
bekommen. Der Verlust durch die Meldung von Fake-Elektronik und der
Geldverlust wiegt hingegen schon etwas schwerer.
Mike J. schrieb:> Machst du die Verkäufer darauf auch aufmerksam und forderst dein Geld> zurück?
Sie wurden erfolgreich als "counterfeit product" reklamiert.
Es reichte die Analyse des ROMtable identity code 3B h = 59
> Wenn die Verkäufer ihr eigenes Verhalten irgend einen Plunder zu> verkaufen entweder nicht erkennen oder gut damit weg kommen, dann machen> sie es immer weiter.> Die überlegen sich erst dann ob diese Masche sich lohnt, wenn sie> dadurch Nachteile erleiden. (also wenn sie es am Geldbeutel merken)
Wahrscheinlich wissen viele nicht was sie da eigentlich verkaufen.
Dennoch sollte dem Einhalt geboten werden.
So, zur Vervollständigung der Reihe habe ich heute noch einen
GD32VF103C8T6 für euch, das RISC-V-Modell von Gigadevice:
https://richis-lab.de/STM32_10.htm
Danke André!
André hat mir noch einen weiteren dubiosen STM32 zukommen lassen. Es war
bei einer Bestellung von CK32-Controller enthalten:
https://www.richis-lab.de/STM32_04.htm
Die Beschriftung ist "anders schlecht" und es ist wieder ein CKS32-Die
enthalten.
By the way:
Aus dem EEVblog-Forum kommt der Hinweis, dass unter anderem der
STM32F103 zur Little-Piranha-Familie zählt:
http://www.farnell.com/datasheets/1443552.pdf
Es könnte daher gut sein, dass das kleine Kunstwerk auf den originalen
Dies kleine, freundliche Piranhas darstellt:
https://www.richis-lab.de/STM32_02.htm
Ich habe nun die APM32F103 erhalten.
Bilder dazu gibt es unter
Beitrag "Re: Neue MCU APM32F103"
Das testen und auslesen der Romtable hat ein überraschendes Ergebnis
erbracht!
1
DWT (Data Watchpoint and Trace) FFF02003 h = 4293926915
Dies entspricht exakt der MCU von
Beitrag "Re: STM32F103C8T6 - Fälschung von ST bestätigt"
Somit wissen wir nun wer die Chips für diese Blue Pills hergestellt hat.
Es gibt jedoch ein anderes Verhalten in vielen Details.
Die Testprogramme laufen alle, aber die MCU ließ sich nicht über ST-Link
programmieren, sondern nur über die UART.
Beitrag "Re: Neue MCU APM32F103"
Inzwischen habe ich herausgefunden, dass bei meinen BluePills der
OCN-Pin der Timer keine Funktion hat.
Betroffen sind ebenfalls die Boards die ich 2017 gekauft habe. Die
Behauptung dass früher(TM) die Chips Originale waren, ist damit nicht
mehr so einfach zu halten.
Für einen Echtheitscheck würde ich daher vorschlagen den Timer auf PWM
zu konfigurieren und den OCN-Pin zu messen.
Zwei Forscherkollegen und ich haben uns näher mit der Security der
STM32F1 Serie und Ersatzchips bzw. Clones beschäftigt.
Wir haben dies im Paper "One Exploit to Rule them All? On the Security
of Drop-in Replacement and Counterfeit Microcontrollers"
zusammengefasst.
Uns interessierte die Frage, wie stark der Ausleseschutz des
Flashspeichers ist und ob es eine Schwachstelle gibt, die ALLE diese
Chips zugleich betrifft.
Es ist nicht völlig klar, wie ähnlich sich diese Chips letztendlich sind
und wie exakt auch Sicherheitsmechanismen korrekt kopiert wurden.
Hierfür haben wir uns die folgenden Chips im Detail angesehen:
APM32F103
CKS32F103
GD32F103
GD32F130
GD32VF103
STM32F103
Das Ergebnis: Die Chips scheinen alle relativ unabhängig voneinander
entwickelt worden zu sein, was anhand der Die-Bilder schon nahe lag.
Auch die Sicherheitskonzepte lassen praktisch nur diesen Schluss zu.
Es zeigte sich bei allen getesteten Chips, dass es große Schwachstellen
im Flashdaten-Ausleseschutz gibt. Diese Sicherheitslücken unterscheiden
sich aber stark voneinander, wir haben KEINE gemeinsame Schwachstelle
gefunden, die alle Chips betrifft. Jeder Hersteller hat offenbar
versucht, selbst Security zu implementieren, es sind ihm dabei aber
Fehler unterlaufen, welche das Sicherheitskonzept zunichte machen.
Im Endeffekt ist die komplette Firmware in allen Chips (auch im
Original!) vollständig exponiert, wobei sich der Aufwand zur Extraktion
je nach Device etwas unterscheidet. Es bleibt aber alles auf einem
do-it-yourself-level, wir sprechen hier von in der Praxis relevanten
Angriffen, da diese auch ohne Speziallabor durchführbar sind!
Wer selbst experimentieren will: Die Details stehen im Paper, dort gibts
auch einen Link zu unseren Proofs-of-Concepts.
Paper: https://www.usenix.org/system/files/woot20-paper-obermaier.pdf
Vortrag: https://www.usenix.org/conference/woot20/presentation/obermaier
Das ist wirklich interessant - Danke!
Dies bedeutet in der Praxis das ein Schutz des Flash-Speichers mit
relativ einfachen Mitteln wie einem Debugger und dem richtigen Exploit
auszuhebeln ist, aber nicht der gesamte Speicher auf diese Art und Weise
auslesbar ist (ca. 90%)?
Karsten W. schrieb:> Dies bedeutet in der Praxis das ein Schutz des Flash-Speichers mit> relativ einfachen Mitteln wie einem Debugger und dem richtigen Exploit> auszuhebeln ist, aber nicht der gesamte Speicher auf diese Art und Weise> auslesbar ist (ca. 90%)?
Ja, solange ich nur mit Debugger rangehe, komme ich bei einigen Chips
nicht an den kompletten Inhalt (z.B. APM32F1 oder STM32F1). Wenn ich
dann aber Hardwareangriffe hinzunehme (Invasiv oder Glitch), dann
erreiche ich die 100%.
Dennoch ist immer Vorsicht angesagt: Es kann immer noch was geben, was
auch wir übersehen haben.
Johannes O. schrieb:> Das Ergebnis: Die Chips scheinen alle relativ unabhängig voneinander> entwickelt worden zu sein, was anhand der Die-Bilder schon nahe lag.> [...]> Jeder Hersteller hat offenbar> versucht, selbst Security zu implementieren,
Danke! Daraus ziehe ich mal den Schluss, dass die Chinesen zwar
vollständige Eigenentwicklungen auf Hardwareebene machen könnten, es
aber (vorerst) nicht wollen. Ausreichend sogar für mehrere Hersteller.
Heißt, solange STM32 aus deren Sicht hinreichend dominant ist, werden
sie STM32-kompatibel bleiben - und wenn sich etwas anderes ergibt,
werden sie umstricken. (Wie man an den RISC V-Varianten sieht.)
In Sachen Hardware haben "wir" damit endgültig die Dominanz verloren,
allerdings noch nicht im Softwarebereich.
Thread beobachten
Seitenaufteilung abschalten