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! ;-)
Carl D. schrieb: > Ja, irgendwer hat das Beweismaterial verbrannt! > > ;-) LOL Aber es existieren Fotos!
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!
Uiuiui, hier wird übelste Hardwarepiraterie ausgetauscht. Ihr wollt den auch noch nachbauen? Gibs zu.
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.
Helwein V. schrieb: > Ihr wollt den auch noch nachbauen? Gibs zu. Nur, wenn du mir die Fab dazugibst. :)
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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:
1 | #1 Aufschrift "STM32F103C8T6 MYS" |
2 | - Raw-Dump für pid = 0xe00fffe0" |
3 | 0xe00fffe0 10 00 00 00 04 00 00 00 0A 00 00 00 00 00 00 00 |
4 | 0xe00ffff0 0D 00 00 00 10 00 00 00 05 00 00 00 B1 00 00 00 |
5 | - dekodiert |
6 | family = 0x00000410 |
7 | designer = 0x000000a0 |
8 | used = true |
9 | identity_code = 0x00000020 (-> "COMPANY-Eintrag") |
10 | continuation_code = 0x00000000 (-> "bank one") |
11 | - Ergebnis |
12 | Hersteller anhand JEDEC-Code ist "STMicroelectronics" |
1 | #2 Aufschrift "STM32F103C8T6 CHN" |
2 | - s.o. (exakt die gleichen Werte wie unter "#1") |
3 | - Ergebnis |
4 | Herstellerangabe durch JEDEC-Code: "STMicroelectronics" |
1 | #3 Aufschrift "CKS32F103C8T6" |
2 | - Raw-Dump für pid = 0xe00fffe0" |
3 | 0xe00fffe0 C3 00 00 00 B4 00 00 00 0B 00 00 00 00 00 00 00 |
4 | 0xe00ffff0 0D 00 00 00 10 00 00 00 05 00 00 00 B1 00 00 00 |
5 | - dekodiert |
6 | family = 0x000004c3 |
7 | designer = 0x000000bb |
8 | used = true |
9 | identity_code = 0x0000003b (-> "COMPANY-Eintrag") |
10 | continuation_code = 0x00000004 (-> "bank five") |
11 | - Ergebnis |
12 | Hersteller anhand JEDEC-Code ist "ARM Ltd." |
Die Chips #1 und #2 wurden von mir bei unterschiedlichen Aliexpress-Händlern gekauft. Der Chip #3 behauptet von "ARM Ltd." hergestellt zu sein(?).
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Karsten M. schrieb: > Daher wäre eine ausführbare Software direkt zum flashen und testen der > Blue-Pills von Vorteil - wie bereits mehrfach vorgeschlagen. Diese existiert in diesem Thread als Anhang bereits, siehe: Beitrag "Re: STM32F103C8T6 - Fälschung von ST bestätigt" Wenn Du die HEX-Datei flashst, werden anschließend auf dem USART (PA9,PA10) die Analysedaten mit 115200Bd 8N1 ausgegeben. Mehr Infos zur Blinky-Test-Firmware (Greaseweazle): https://github.com/keirf/Greaseweazle/wiki/STM32-Fakes
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
Blue-1.1.jpg
330 KB -
Blue-1.2.jpg
230 KB
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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=120 Cyblord -. 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Blue-2.jpg
480 KB
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.
:
Bearbeitet durch Moderator
Zur Erinnerung: Die Fakes, die im Ausgangsposting genannt wurden, weisen mindestens die folgenden Fehler auf:
1 | - Cannot program at 921600 baud. Success at 115200 baud. |
2 | - Cannot start firmware from System Bootloader (Bootloader may not |
3 | set the Reset SP?) |
4 | - Debug registers return valid non-zero info (contravenes Erratum |
5 | 2.3 of genuine parts) |
6 | - Writing to backup registers, and then turning off the backup |
7 | interface clock, seems to lock up parts of the chip: Future writes |
8 | to certain registers hang forever with no exception or reset |
9 | - I2C peripheral won't allow CR1_ACK to be set in the same write that |
10 | sets CR1_PE |
11 | - DMA peripheral generates spurious extra completion interrupts and |
12 | is generally prone to lockup |
Quelle: https://github.com/keirf/Greaseweazle/wiki/STM32-Fakes Hier die Ausgabe des Blinky-Tests bei einem Fake, wie im Ausgangsposting beschrieben:
1 | ** Blinky Test ** |
2 | ** Keir Fraser <keir.xen@gmail.com> |
3 | ** https://github.com/keirf/Greaseweazle |
4 | Serial = 7814:046f:101e:0200:07e2:1607 |
5 | Flash Size = 64kB |
6 | Device ID = 0x0410 |
7 | Revision = 0x2003 |
8 | **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.
:
Bearbeitet durch Moderator
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?
Angehängte Dateien:
-
STM32F103C8T6.jpg
93 KB
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? |
9 | Testing I2C1... OK |
10 | Testing I2C2... OK |
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... OK |
18 | DMA Test #2... OK |
19 | DMA Test #3... OK |
20 | DMA Test #4... OK |
21 | Testing 64kB Flash... OK |
22 | Enable TIM4 IRQ... .OK |
[Mod] Doppeltes Bild gelöscht
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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!"
:
Bearbeitet durch User
Ich habe neue "STM32-Varianten" erhalten. Für mehr Ordnung habe ich eine Übersichtsseite erstellt: https://richis-lab.de/STM32.htm Neu ist der CKS32: https://richis-lab.de/STM32_03.htm Und ein weiterer STM32 aus einem Bluepill-Board: https://richis-lab.de/STM32_04.htm Es handelt sich hier um einen umgelabelten CKS32!
:
Bearbeitet durch User
Richard K. schrieb: > Für mehr Ordnung habe ich eine Übersichtsseite erstellt: > https://richis-lab.de/STM32.htm Richi´s Lab? --> http://www.Deppenapostroph.info
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.
:
Bearbeitet durch User
Deudschleera schrieb: > Richard K. schrieb: >> Für mehr Ordnung habe ich eine Übersichtsseite erstellt: >> https://richis-lab.de/STM32.htm > > Richi´s Lab? > > --> http://www.Deppenapostroph.info => https://www.ef.de/englisch-hilfen/englische-grammatik/apostroph/
:
Bearbeitet durch User
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.
Richard K. schrieb: > Neu ist der CKS32: > https://richis-lab.de/STM32_03.htm Hier sind ebenfalls ein Schwung dreiste Fälschungen angekommen: https://www.aliexpress.com/item/10pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module/1811770307.html Die Blink-LED ist hier blau und nicht grün und es ist direkt ein Blink-Programm geflasht.
1 | st-info --probe |
2 | serial: 523f6b06483f50523943123f |
3 | openocd: "\x52\x3f\x6b\x06\x48\x3f\x50\x52\x39\x43\x12\x3f" |
4 | flash: 65536 (pagesize: 1024) |
5 | sram: 20480 |
6 | chipid: 0x0410 |
7 | descr: F1 Medium-density device |
8 | karsten@PC10:/win/STM/stlink/build/Release$ ./st-info --probe |
9 | Found 1 stlink programmers |
10 | serial: 523f6b06483f50523943123f |
11 | openocd: "\x52\x3f\x6b\x06\x48\x3f\x50\x52\x39\x43\x12\x3f" |
12 | flash: 65536 (pagesize: 1024) |
13 | sram: 20480 |
14 | chipid: 0x0410 |
15 | descr: F1 Medium-density device |
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.
:
Bearbeitet durch User
Karsten M. schrieb: > Hier sind ebenfalls ein Schwung dreiste Fälschungen angekommen: > https://www.aliexpress.com/item/10pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module/1811770307.html Naja, so semi-dreist. Immerhin steht in der Produktbeschreibung in der ersten Zeile: > This is a core chip based on for CS32F103C8T6 ARM core board Dreist finde ich es aber trotzdem, weil Titel und Abbildungen einen STM32 suggerieren. Das würde ich mal beim Ali reklamieren.
Dreist ist vor allem wenn die Teile nicht funktionieren! Bislang gab es noch keine Blue-Pills auf denen einfach keine Programmierung läuft.
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?
:
Bearbeitet durch User
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 | ROMtable identity code 3B = 59 |
2 | ROMtable continuation code 4 = 4 |
3 | ROMtable family 4C3 = 1219 |
4 | ROMtable designer BB = 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: > ROMtable identity code 3B = 59 > ROMtable continuation code 4 = 4 Laut https://github.com/a-v-s/ucdev/blob/master/demos/cortex_romtable/stm32f1/main.c#L137 ein CS32 oder ein APM32. Ich vermute eher ein CS32.
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.
:
Bearbeitet durch User
Und wie schaut man nach der ETM? In dem Artikel steht es nicht beschrieben. Wenn man gurgelt kommen nur Hinweise auf ein CPUID Register für Cortex M7 ... http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0489d/Cihhbddh.html Nachtrag: Hier für M1 als PDF
:
Bearbeitet durch User
Karsten M. schrieb: > Und wie schaut man nach der ETM? https://github.com/a-v-s/ucdev/blob/master/demos/cortex_romtable/stm32f1/main.c#L141 https://github.com/a-v-s/libhalglue/blob/master/common/arm_cpuid.h#L39
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
:
Bearbeitet durch User
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 | typedef struct { |
6 | uint32_t nvic; |
7 | uint32_t dwt; |
8 | uint32_t fpb; |
9 | uint32_t itm; |
10 | uint32_t tpiu; |
11 | uint32_t etm; |
12 | uint32_t end; |
13 | // ... ///
|
14 | } cortex_m_romtable_t; |
Durch den ganzen Dschungel blickt man einfach nicht durch ...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Angehängte Dateien:
-
Blue-Pill.jpg
61 KB
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?
:
Bearbeitet durch User
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?
Karsten M. schrieb: > Danke - ein schöner Hinweis, aber für einen Anfänger nicht konkret > genug. ;-) Dann könntest du dir direkt sein Binary holen: https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/msg2910694/#msg2910694
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:
1 | [ 1059.388206] usb 1-3.1: new full-speed USB device number 12 using ehci-pci |
2 | [ 1059.460235] usb 1-3.1: device descriptor read/64, error -32 |
3 | [ 1059.636207] usb 1-3.1: device descriptor read/64, error -32 |
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:
1 | [ 1293.809774] usb 1-3.1: new full-speed USB device number 16 using ehci-pci |
2 | [ 1293.904049] usb 1-3.1: New USB device found, idVendor=0483, idProduct=5740 |
3 | [ 1293.904061] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 |
4 | [ 1293.904068] usb 1-3.1: Product: BLUEPILL_F103C8 CDC in FS Mode |
5 | [ 1293.904073] usb 1-3.1: Manufacturer: STMicroelectronics |
6 | [ 1293.904078] usb 1-3.1: SerialNumber: 0250585C5343 |
7 | [ 1293.935245] cdc_acm 1-3.1:1.0: This device cannot do calls on its own. It is not a modem. |
8 | [ 1293.935282] cdc_acm 1-3.1:1.0: ttyACM0: USB ACM device |
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Karsten M. schrieb: > Die MCU hat definitiv nur 64 KB Flash und nicht 128 KB wie die anderen > Blue-Pills. 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
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.)
1 | /usr/share/openocd/scripts# openocd -f board/board.cfg |
2 | Open On-Chip Debugger 0.8.0 (2018-01-21-21:53) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.sourceforge.net/doc/doxygen/bugs.html |
6 | Runtime Error: embedded:startup.tcl:47: Can't find board/board.cfg |
7 | in procedure 'script' |
8 | at file "embedded:startup.tcl", line 47 |
Dieses System ist nicht so Mal eben aufgesetzt. Hast Du eine passende Konfiguration für eine Blue-Pill?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Mit der board.cfg von der Artikelseite:
1 | $ openocd -f board.cfg |
2 | Open On-Chip Debugger 0.8.0 (2018-01-21-21:53) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.sourceforge.net/doc/doxygen/bugs.html |
6 | none separate |
7 | Error: session's transport is not selected. |
8 | Runtime Error: embedded:startup.tcl:20: |
9 | in procedure 'script' |
10 | at file "embedded:startup.tcl", line 58 |
11 | at file "board.cfg", line 14 |
12 | in procedure 'swj_newdap' called at file "/usr/share/openocd/scripts/target/stm32f1x.cfg", line 37 |
13 | in procedure 'transport' called at file "/usr/share/openocd/scripts/target/swj-dp.tcl", line 26 |
14 | in procedure 'ocd_bouncer' |
15 | at file "embedded:startup.tcl", line 20 |
Mit Deiner Datei:
1 | $ openocd -f board.cfg |
2 | Open On-Chip Debugger 0.8.0 (2018-01-21-21:53) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.sourceforge.net/doc/doxygen/bugs.html |
6 | Error: Debug adapter doesn't support 'swd' transport |
7 | Runtime Error: embedded:startup.tcl:20: |
8 | in procedure 'script' |
9 | at file "embedded:startup.tcl", line 58 |
10 | in procedure 'transport' called at file "board.cfg", line 5 |
11 | in procedure 'ocd_bouncer' |
12 | at file "embedded:startup.tcl", line 20 |
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
1 | $ openocd -f board.cfg |
2 | Open On-Chip Debugger 0.8.0 (2018-01-21-21:53) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.sourceforge.net/doc/doxygen/bugs.html |
6 | none separate |
7 | Error: session's transport is not selected. |
8 | Runtime Error: embedded:startup.tcl:20: |
9 | in procedure 'script' |
10 | at file "embedded:startup.tcl", line 58 |
11 | at file "board.cfg", line 14 |
12 | in procedure 'swj_newdap' called at file "/usr/share/openocd/scripts/target/stm32f1x.cfg", line 37 |
13 | in procedure 'transport' called at file "/usr/share/openocd/scripts/target/swj-dp.tcl", line 26 |
14 | in procedure 'ocd_bouncer' |
15 | at file "embedded:startup.tcl", line 20 |
Dies ist scheinbar ein recht bockiges System. ;-)
Unter Debian 10 sieht es tatsächlich besser aus:
1 | $ openocd -f board.cfg |
2 | Open On-Chip Debugger 0.10.0 |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.org/doc/doxygen/bugs.html |
6 | none separate |
7 | Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. |
8 | Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD |
9 | adapter speed: 1000 kHz |
10 | adapter_nsrst_delay: 100 |
11 | none separate |
12 | Info : Unable to match requested speed 1000 kHz, using 950 kHz |
13 | Info : Unable to match requested speed 1000 kHz, using 950 kHz |
14 | Info : clock speed 950 kHz |
15 | Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748 |
16 | Info : using stlink api v2 |
17 | Info : Target voltage: 3.252232 |
18 | Warn : UNEXPECTED idcode: 0x2ba01477 |
19 | Error: expected 1 of 1: 0x1ba01477 |
20 | in procedure 'init' |
21 | in procedure 'ocd_bouncer' |
Aber es scheitert an dem anderen inzwischen bekannten ID-Code.
Neue Überraschung:
1 | Trying ::1... |
2 | Trying 127.0.0.1... |
3 | Connected to localhost. |
4 | Escape character is '^]'. |
5 | Open On-Chip Debugger |
6 | > reset halt |
7 | target halted due to debug-request, current mode: Thread |
8 | xPSR: 0x01000000 pc: 0x00004e22 msp: 0x2000038c |
9 | > flash probe 0 |
10 | device id = 0x20036410 |
11 | ignoring flash probed value, using configured bank size |
12 | flash size = 128kbytes |
13 | flash 'stm32f1x' found at 0x08000000 |
14 | > flash write_image erase bh20k.bin 0x08000000 |
15 | auto erase enabled |
16 | flash write algorithm aborted by target |
17 | flash write failed at address 0x8010002 |
18 | flash memory not erased before writing |
19 | error writing to flash at address 0x08000000 at offset 0x00000000 |
Mit originaler stm32f1x.cfg erhält man 64 KB Flash vorgeschlagen
1 | Trying ::1... |
2 | Trying 127.0.0.1... |
3 | Connected to localhost. |
4 | Escape character is '^]'. |
5 | Open On-Chip Debugger |
6 | > reset halt |
7 | target halted due to debug-request, current mode: Thread |
8 | xPSR: 00000000 pc: 0x00000002 msp: 0x04364d40 |
9 | > flash probe 0 |
10 | device id = 0x20036410 |
11 | flash size = 64kbytes |
12 | flash 'stm32f1x' found at 0x08000000 |
:
Bearbeitet durch User
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? :-)
:
Bearbeitet durch User
> 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...
Angehängte Dateien:
-
stm32f108C8_Board.jpg
79 KB
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.
R. M. schrieb: https://robotdyn.com/black-pill-apm32f103cb-128kb-flash-20kb-sram-stm32-compatible-arm-cortexr-m3-mcu-mini-board.html Das sieht ja wirklich interessant aus. Hat schon jemand Erfahrungen mit der Unterstützung durch die FPU gemacht? (Unterstützung durch den Compiler, Geschwindigkeitsgewinn)
:
Bearbeitet durch User
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: > habe Tomaten auf den Augen Guck mal ganz unten. Die verschwinden nicht, sondern tauchen an anderer Stelle auf.
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.
Karsten M. schrieb: > R. M. schrieb: > https://robotdyn.com/black-pill-apm32f103cb-128kb-flash-20kb-sram-stm32-compatible-arm-cortexr-m3-mcu-mini-board.html > > Das sieht ja wirklich interessant aus. > > Hat schon jemand Erfahrungen mit der Unterstützung durch die FPU > gemacht? > (Unterstützung durch den Compiler, Geschwindigkeitsgewinn) 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.
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?
Ihr redet aneinander vorbei: https://www.aliexpress.com/item/33016045350.html vs. https://www.aliexpress.com/item/32802556794.html
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
:
Bearbeitet durch User
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. Nee... Karsten hat den APM32F103 gemeint, nicht den STM32F103. Man beachte das APM. Der APM hat eine "komische" FPU als Peripherie Modul. Leider keine genau Doku: https://www.apexmic.com/uploads/tool/APM32F103x4x6x8xB%20Data%20Sheet%20V1.0.5.pdf Man beachte S. 33 im Datenblatt. Homepage: https://www.apexmic.com/en/newproduct/apm2/16
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.
2⁵ schrieb: > Nee... Karsten hat den APM32F103 gemeint, nicht den STM32F103. Man > beachte das APM. Der APM hat eine "komische" FPU als Peripherie Modul. > Leider keine genau Doku: > https://www.apexmic.com/uploads/tool/APM32F103x4x6x8xB%20Data%20Sheet%20V1.0.5.pdf > Man beachte S. 33 im Datenblatt. Homepage: > https://www.apexmic.com/en/newproduct/apm2/16 Hier ist diese MCU als eine von vielen weiteren Fakes aufgelistet: https://www.blaatschaap.be/?p=120 von https://www.cnx-software.com/2020/03/22/how-to-detect-stm32-fakes/#comment-571372 The competors: STM32F103 GD32F103 APM32F103 BLM32F103 CS32F103 MM32F103
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.zip https://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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
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 ...
Es ist wirklich an der Zeit das Thema APM32F103 auszukoppeln: Beitrag "Neue MCU APM32F103" Bitte nun hier fortführen.
Angehängte Dateien:
-
BluePill-2.jpg
360 KB
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
Wie meldet sich denn das hex von https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/msg2910694/#msg2910694 ?
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 )
:
Bearbeitet durch User
Hallo André, es würde mich natürlich freuen wenn du mir die GD32VF103CBT6 auch noch schickst! :) Danke! Viele Grüße, Richard
Die Chips sind verschickt. Da sind auch zwei HK32 dabei. Die haben die gleiche Markierungen im Eck als das Bild der erste Fälschung.
So, ich habe die Reihe um den MM32F103CBT6 erweitert: https://richis-lab.de/STM32_07.htm Danke André! Viele Grüße, Richard
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
Die Reise dahin war jetzt wirklich spannend. Danke schonmal dafür!
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!
Angehängte Dateien:
-
STM.jpg
140 KB
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 (Data Watchpoint and Trace) FFF02003 h = 4293926915 |
2 | ETM FFF42003 h = 4294189059 |
3 | CPUID 412FC231 h = 1093648945 |
4 | CPUID Revision 1 h = 1 |
5 | CPUID PartNo C23 h = 3107 |
6 | CPUID Architecture F h = 15 |
7 | CPUID Variant 2 h = 2 |
8 | CPUID Implementer 41 h = 65 |
9 | ROMtable identity code 3B h = 59 |
10 | Hersteller: ARM Ltd. |
11 | ROMtable continuation code 4 h = 4 |
12 | ROMtable family 4C3 h = 1219 |
13 | ROMtable designer BB h = 187 |
Dieses Mal hat der Chip jedoch 128 KB Speicher. Das Testprogramm Greaseweazle funktioniert darauf nicht.
1 | istm32id
|
2 | Die xy coords: 16871067 |
3 | Wafer Number: 16 |
4 | Lot_num ascii encoded [23:0]: 0x00534713 | S G . |
5 | Lot_num ascii encoded [55:24]: 0x004E4C38 | . N L 8 |
6 | |
7 | Testing 64kB Flash block: 0x10000 - 0x1FFFF |
8 | Erasing
|
9 | Flash with 1010101010101010 (0xAA) |
10 | Testing for 0xAA - OK |
11 | Erasing
|
12 | Flash with 0101010101010101 (0x55) |
13 | Testing for 0x55 - OK |
14 | Erasing
|
15 | ~~~~~ ALL TESTS PASSED ~~~~~ |
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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 |
2 | ETM FFF42002 h = 4294189058 |
3 | CPUID 412FC231 h = 1093648945 |
4 | CPUID Revision 1 h = 1 |
5 | CPUID PartNo C23 h = 3107 |
6 | CPUID Architecture F h = 15 |
7 | CPUID Variant 2 h = 2 |
8 | CPUID Implementer 41 h = 65 |
9 | ROMtable identity code 3B h = 59 |
10 | Hersteller: ARM Ltd. |
11 | ROMtable continuation code 4 h = 4 |
12 | ROMtable family 4C3 h = 1219 |
13 | ROMtable designer BB h = 187 |
14 | Counter= 50 VRef(mv)= 3330 Temp(°C)= 278 A0(mv)= 370 |
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"
1 | ** Blinky Test ** |
2 | ** Keir Fraser <keir.xen@gmail.com> |
3 | ** https://github.com/keirf/Greaseweazle |
4 | Serial = 0036:0037:0013:5900:4a33:4e4d |
5 | Flash Size = 128kB |
6 | Device ID = 0x0000 |
7 | Revision = 0x0000 |
8 | Testing I2C1... OK |
9 | Testing I2C2... OK |
10 | Testing SPI1... OK |
11 | Testing SPI2... OK |
12 | Testing TIM1... OK |
13 | Testing TIM2... OK |
14 | Testing TIM3... OK |
15 | Testing TIM4... OK |
16 | DMA Test #1... OK |
17 | DMA Test #2... OK |
18 | DMA Test #3... OK |
19 | DMA Test #4... OK |
20 | Testing 64kB Flash... OK |
21 | Enable TIM4 IRQ... .OK |
22 | Testing 20kB SRAM (endless loop)............................................... |
23 | |
24 | |
25 | istm32id |
26 | Die xy coords: 3604534 |
27 | Wafer Number: 19 |
28 | Lot_num ascii encoded [23:0]: 0x00590000 | Y . . |
29 | Lot_num ascii encoded [55:24]: 0x4E4D4A33 | N M J 3 |
30 | |
31 | Testing 64kB Flash block: 0x10000 - 0x1FFFF |
32 | Erasing |
33 | Flash with 1010101010101010 (0xAA) |
34 | Testing for 0xAA - OK |
35 | Erasing |
36 | Flash with 0101010101010101 (0x55) |
37 | Testing for 0x55 - OK |
38 | Erasing |
39 | ~~~~~ ALL TESTS PASSED ~~~~~ |
:
Bearbeitet durch User
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%)?
:
Bearbeitet durch User
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.
Beitrag #6369521 wurde von einem Moderator gelöscht.
Beitrag #6369528 wurde von einem Moderator gelöscht.
Beitrag #6369599 wurde von einem Moderator gelöscht.
Ich weise hier auf die Nutzungsbestimmungen hin: https://www.mikrocontroller.net/articles/Hilfe:Forum_Nutzungsbedingungen Beteiligung an einer Diskussion unter verschiedenen Namen ist nicht erlaubt. Beleidigungen ebenso nicht.
Beitrag #6369936 wurde von einem Moderator gelöscht.
Beitrag #6370723 wurde von einem Moderator gelöscht.
Beitrag #6370735 wurde von einem Moderator gelöscht.
Beitrag #6370775 wurde von einem Moderator gelöscht.
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.