STM32F103C8T6 - Fälschung von ST bestätigt

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

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.

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.

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:
> Die Chips #1 und #2 wurden von mir bei unterschiedlichen
> Aliexpress-Händlern gekauft.

Was beweisen würde, daß man auch bei Ali Originale zu günstigen Preisen 
kaufen kann.

> Der Chip #3 behauptet von "ARM Ltd." hergestellt zu sein(?).

Der Aufdruck "CKS32F103C8T6" (wohl eher "CS32F103C8T6") versucht gar 
nicht erst, einen STM32F103 vorzutäuschen. Welchen Status die Chips von 
CKS haben (ob sie z.B. eine Lizenz von ARM haben) ist ungewiß. Dito 
inwieweit sie funktionieren.

Wenn der Händler dir Boards mit STM32F103 bewirbt/verkauft, dann aber 
CS32F103 geliefert hat, ist das aber auch unerheblich. "Ware nicht wie 
beschrieben" reicht dann als Grund für die Retoure.

Axel S. schrieb:
> ...wohl eher "CS32F103C8T6"...

Der Aufdruck ist tatsächlich "CKS32F103C8T6".
Der CKS32 ist in einen meiner STLink-V2 verbaut. Ich beanstande da 
nichts. Mir ging es um den ROM-Table-Eintrag.

Zu den ganzen Antworten oben:
Das ist alles richtig aber andererseits gar nicht das Thema.

Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man 
einen STM32 Controller verwendet und keinen z.B. von Atmel oder 
Microchip.
Dies führt dann zu der Frage welche ARM-CPU gebrauchsfertig für welchen 
Preis zu bekommen ist.

Das Fazit dieser Diskussion ist die interessante Frage, warum 
ausgerechnet die preiswerteren STM32 MCU's gefälscht werden, während die 
deutlich größeren Hx CPU's in Lizenz produziert werden.
Bei den Preisen für die Orange-Pi's kann so eine H3 CPU auf jeden Fall 
nicht viel Kosten und dennoch können diese für den Preis zu einem 
gleichbleibenden Qualitätsniveau angeboten werden.
Bei den Blue-Pill's ist die Hardware echte Lotterie!

Das mit den ID's bei den Fälschungen ist ebenfalls recht erstaunlich, 
aber hilft eigentlich nur die Fälschungen festzustellen.
Interessanter ist doch die Frage ob die MCU trotzdem korrekt arbeitet 
oder nicht?

Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus so 
viel kostet wie ein neues IC beim Produzent, kann doch keiner ernsthaft 
erwarten ein neues Original zu erhalten.

Karsten M. schrieb:

> Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus so
> viel kostet wie ein neues IC beim Produzent, kann doch keiner ernsthaft
> erwarten ein neues Original zu erhalten.

Auch die Originale sind in Asien mitunter erheblich billiger als hier, 
weil einfach viel größere Mengen davon verarbeitet werden und weil 
vieles davon auch dort produziert wird und deshalb die Wege von der 
Chipfabrik zum Bestücker kürzer sind.

Ich habe leztes Jahr mal bei Bosch nachgefragt, wie wahrscheinlich es 
ist, dass es sich bei den BME280 um Fälschungen handelt, die man bei 
AliExpress auf Platinen samt Hühnerfutter für weniger als 2 Euro 
bekommt, während der nackte Chip hier beim Distributor in Kleinmengen 
5-6 Euro kostet. Die Antwort war, dass Fälschungen eher unwahrscheinlich 
sind, vor allem wenn die Druckmessung plausible Werte liefert, und dass 
der Preis für den asiatischen Markt durchaus realistisch ist.

Karsten M. schrieb:
> Das ist alles richtig aber andererseits gar nicht das Thema.

Da gehen unsere Meinungen auseinander. Deutlich.

> Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man
> einen STM32 Controller verwendet und keinen z.B. von Atmel oder
> Microchip.

Nein, darum geht es nicht. Es geht darum, was man tun kann (und sollte) 
wenn man ein Bauteil oder eine Platine gekauft hat, die damit beworben 
wird daß ein STM32xxx drauf ist, aber etwas anderes geliefert bekommt.

> Das Fazit dieser Diskussion ist die interessante Frage, warum
> ausgerechnet die preiswerteren STM32 MCU's gefälscht werden

Das ist doch trivial: das Produkt "Bluepill" hat einen ausgezeichneten 
Ruf und wird den Händlern förmlich aus den Händen gerissen. Natürlich 
nutzen Trittbrettfahrer das aus. Das ist bei Arduino nano genauso.

> Das mit den ID's bei den Fälschungen ist ebenfalls recht erstaunlich,
> aber hilft eigentlich nur die Fälschungen festzustellen.
> Interessanter ist doch die Frage ob die MCU trotzdem korrekt arbeitet
> oder nicht?

Das ist auch eine interessante Frage, aber nicht in diesem Zusammenhang. 
Wenn ein Händler ein "Bluepill" Board anbietet und dazu schreibt, daß 
ein z.B. CS32F103 da drauf ist - dann ist das eine relevante Frage. 
Denn die Antwort entscheidet darüber ob man das kaufen will (und ob man 
den gleichen Preis bezahlen will wie für eins mit STM32).

> Wenn ein fertiges Produkt wie eine Blue-Pill weniger oder fast genaus so
> viel kostet wie ein neues IC beim Produzent, kann doch keiner ernsthaft
> erwarten ein neues Original zu erhalten.

Diese Logik funktioniert nicht. Es wurden ja jahrelang Bluepill Boards 
zu derart geringen Preisen verkauft. Und die µC da drauf sind nach allem 
was man weiß, auch echt. Keiner weiß warum die so billig sind. Aber es 
gibt etliche Möglichkeiten:

- Chips die irgendwelche Nebenkenngrößen nicht einhalten und von ST 
eigentlich als Ausschuß entsorgt würden, sind im Graumarkt gelandet

- die Fab in Malaysia oder China hat "Überstunden" gemacht und die 
erzeugte Ware auf den Graumarkt geworfen

- ein Großkunde hat sich bei ST eingedeckt und ist Pleite gegangen, die 
Chips aus der Konkursmasse sind auf dem Graumarkt gelandet

In all diesen Fällen (ohne Anspruch auf Vollständigkeit) wären das echte 
ST-Chips, die unter dem Mikroskop und mit den meisten Tests als 
Originale durchgehen würden.

Axel S. schrieb:
> Da gehen unsere Meinungen auseinander. Deutlich.

Nicht wirklich.
Der Gedankengang mit den Orange-Pi's war leider irreführend und 
off-topic.
Er sollte nur aufzeigen das es ab ca. $20 noch andere Hardware für 
Lösungen gibt und das diese dann nicht mit Klonen, sondern eigenen 
klaren CPU Typen und Lizenzen arbeitet.

>
>> Bei dem Thema geht es ja letzten Endes um den Preis und darum, warum man
>> einen STM32 Controller verwendet und keinen z.B. von Atmel oder
>> Microchip.
>
> Nein, darum geht es nicht. Es geht darum, was man tun kann (und sollte)
> wenn man ein Bauteil oder eine Platine gekauft hat, die damit beworben
> wird daß ein STM32xxx drauf ist, aber etwas anderes geliefert bekommt.

Nachweisen das es sich um eine minderwertige Fälschung handelt.
Dafür ist die ID schon Mal ein guter Ansatz.

Wenn die Blue-Pill trotz korrekter ID nicht korrekt tickt, wäre ein 
standardisierter Hardware-Test von Vorteil um nachweisen zu können, daß 
die Ware defekt ist.


Wenn man sich nicht rumärgern möchte, dann ist die vorgeschlagene 
Platine von RobotDyn ein guter Kompromiß:
https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-with-arduino-bootloader.html

Karsten M. schrieb:
> Interessanter ist doch die Frage ob die MCU trotzdem korrekt arbeitet
> oder nicht?

Offensichtlich ist das nicht - oder zumindest nicht immer - der Fall. 
Das fängt damit an, das sich manche grundsätzlich nicht wie gewohnt wie 
ein STM32 flashen lassen, über disfunktionale DMA, bis hin zu anderen 
Ausführungszeiten für Code, was dann etwaiges Bitbanging vermasselt. 
Jetzt wäre es nur noch interessant, welcher Abkömmling welche Schwäche 
hat und was genau eigentlich unter der Haube von den falsch deklarierten 
Chips steckt.

Aus dem Grund schließe ich mich mal der Bitte von Uwe Bonnes an. Sehr 
nett wäre es, wenn mal jemand den Test mit einem falsch deklarierten 
F103C8 durchführen würde, also mit einer der zuvor genannten

Frank M. schrieb:
> die im Eingangsposting erwähnten Fakes mit Seriennummer "...MYS 807"
> bzw. "...MYS 901"

Das würde eventuell etwas Licht ins Dunkel bringen.

Karsten M. schrieb:
> 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

Erster Test:

** Blinky Test **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/Greaseweazle
Serial = ff52:066b:8275:5554:5224:8114
Flash Size  = 64kB
Device ID = 0x0000
Revision  = 0x0000
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop).........................


Die Bezeichnung auf dem Chip ist kaum zu lesen, da die Oberfläche 
scheinbar gesandstrahlt wurde.

Karsten M. schrieb:
> DMA Test #1... OK
> DMA Test #2... OK
> DMA Test #3... OK
> DMA Test #4... OK

Das ist nicht weiter verwunderlich. Die Fakes, um die es hier geht, 
haben Vertiefungen an den Ecken. Fotos und Quellen dazu wurden hier 
schon gepostet. Diese steigen dann beim DMA-Test aus mit spurious 
Interrupts.

Cyblord -. schrieb:
> Es klingt sehr weit hergeholt, dass da jemand einen kompletten Nachbau
> from Scratch macht, und dieser hat dann nur ganz bestimmte
> Unzulänglichkeiten unter ganz bestimmten, aber immer gleichen,
> Bedingungen.

Hättet du den Thread richtig gelesen, dann würdest du sowas falsches 
nicht schreiben. Das wurde bereits analysiert und bewiesen, sogar 
Bildmaterial des Die Layouts veröffentlicht.

Cyblord -. schrieb:
> Es klingt sehr weit hergeholt, dass da jemand einen kompletten Nachbau
> from Scratch macht,
Das ist bewiesenes Faktum und wird auf mehreren Seiten im Netz 
diskutiert, u.a. hier:
https://www.blaatschaap.be/?p=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.

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.

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.

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.

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

NichtWichtig schrieb:
> Wie wird den I2C oder SPI oder xxx getestet?
>
> Wie ist die Hardware drumrum aufgebaut um solche Aussagen zu treffen?
>
> Wie wird die langsamere Abarbeitung erfaßt welche ich beobachtet habe?
> Und aus welcher Ecke des µC läßt sich das begründen?
>
> Wie schauts mit der SWD Schnittstelle aus die bei keinem meiner
> FakePills läuft?

Ist alles NichtWichtig - wie der Name bereits sagt. :-)

Deshalb ja mein Vorschlag für ein Testprogramm und einer einfachen 
standardisierten Außenbeschaltung, wo Eingänge mit Ausgängen verbunden 
sind, etc ...
Dann gibt es realere Aussagen was funktioniert.

Frank M. schrieb:
> Das ist normal, ST lieferte bisher die STM32F103C8T6 immer mit 128 KB
> Flash aus, von denen per ST-Link aber immer nur 64KB nutzbar waren. An
> die obere 64KB-Hälfte kommt man nur per Bootloader dran.

Da muss man zwischen ST-Link als PC-Software und dem ST-Link als 
Debugger unterscheiden. Der ST-Link Debugger hat (z.B. mit OpenOCD) kein 
Problem mit den 128kb Flash, weil die Device-ID von F103C8 und F103CB 
sowieso identisch ist (wie übrigens auch der Die). Die ST-Link 
PC-Software liest jedoch das Flash-Size-Register aus und dort steht beim 
F103C8 eben eine 64 drin, wodurch die Software dann meckert.

Für alle, die Fälschungen ganz sicher am Preis erkennen können:
Gestern sind bei mir zwei Blue Pills eingetrudelt, bestellt Anfang 
Dezember zu 1,59€ das Stück inkl. Versand, beide mit Aufdruck

STM32F
103C8T6
9902Q 93
MYS 628

Serial = 0031:066d:3658:3231:4052:4307
Serial = ff56:0669:7249:4951:2614:8716

Beide verhalten sich im Greaseweazle-Test wie Originale.

Es gibt also noch "Gute" (wenn man davon absieht, dass ich bei einem der 
beiden eine längere Lötorgie einlegen musste, weil 9Pins verbogen waren 
und keinen Kontakt zu den Pads hatten.)

P.S.: Hm, vielleicht gibt's auch keine mehr. Ich sehe gerade, dass bei 
dem Angebot nun steht: "Leider, ist dieser Artikel nicht mehr 
verfügbar!"

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!

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.

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/

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

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.

https://richis-lab.de/Howto.htm

Bitteschön...

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.

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.

Hier ging es ebenfalls darum noch einen kleinen Bestand anzulegen.
Tja - dieses Mal hat es leider nicht geklappt.

Die Reklamation als "counterfeit product" wurde bereits problemlos zu 
meinen Gunsten entschieden.
"Refund: USD 16.40  ,no need to return goods （if there is a 
refund,normally buyer will receive the refund in 3-20 business days)"

Es ist jedoch immer noch nicht klar was dort eigentlich verbaut worden 
ist?

Karsten M. schrieb:
> Hier ging es ebenfalls darum noch einen kleinen Bestand anzulegen.
> Tja - dieses Mal hat es leider nicht geklappt.
>
> Die Reklamation als "counterfeit product" wurde bereits problemlos zu
> meinen Gunsten entschieden.
> "Refund: USD 16.40  ,no need to return goods （if there is a
> refund,normally buyer will receive the refund in 3-20 business days)"
>
> Es ist jedoch immer noch nicht klar was dort eigentlich verbaut worden
> ist?

Ich kann bei Bedarf einen Blick rein werfen...

Richard K. schrieb:
>
> Ich kann bei Bedarf einen Blick rein werfen...

Dies wäre eine Option wenn sich den Teilen keinerlei Funktion abgewinnen 
lässt ...

Uwe B. schrieb:
> https://www.blaatschaap.be/?p=95 zeigt, wie man die PIDR ausliest.
> Nochmals die Bitte an die Besitzer von "Fakes", diese RomTable PIDr
> auszulesen und zu posten!

In der Beschreibung oben ist noch ein kleiner Fehler.
Die bestückten LED's sind beide ROT - also die LED an PC13 ist hier rot 
und nicht grün wie sonst üblich.

Das auslesen der ROMTable ergibt ein überraschendes Ergebnis:

1

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.

Was du genau hast, weißt du, wenn du nach der ETM schaust.
Siehe https://www.blaatschaap.be/?p=166

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

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

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

Wie bekommt man am schnellsten das Blinky auf den Bluepill?

Ich habe auch noch einige älter sowie neue Bluepill und würde bei Fake 
das ganze nem Kumpel mit nem 20k Mikroskop und um-Schleifer geben.

Schwuppse schrieb: ...

Die Arbeit kann man sich sparen wie weiter oben bereits festgestellt 
worden ist und man kann sich direkt für $3.49 ein "Original" kaufen:

"Wenn man sich nicht rumärgern möchte, dann ist die vorgeschlagene
Platine von RobotDyn ein guter Kompromiß:
https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-with-arduino-bootloader.html";


Dann entfällt jedoch das spannende forschen und die Diskussion hier ... 
;-)
Scheinbar kann doch über die diversen ID's sowie ein Testprogramm vieles 
herausgefunden werden.

Karsten M. schrieb:
> Scheinbar kann doch über die diversen ID's sowie ein Testprogramm vieles
> herausgefunden werden.

einfach mal dieses Testprogramm draufspielen und schauen.. ich finde es 
interessant, habe IDE und Programmer da.. das Github Projekt ist nur ein 
bisschen unübersichtlich.

Nachtrag aha:
Greaseweazle includes a Blinky test firmware in the alt/ subfolder. When 
written to a correct and working Blue Pill board, this firmware will 
flash the PC13 LED once per second (ie. LED toggles every 500ms).

URL:https://github.com/keirf/Greaseweazle/wiki/STM32-Fakes

Philipp K. schrieb:
> URL:https://github.com/keirf/Greaseweazle/wiki/STM32-Fakes

Dies ist eines der beiden Testprogramme die auf dieser Blue-Pill hängen 
bleiben und nicht funktionieren!

Die bekannten CKS32-Typen laufen mit diesem Testprogramm.
Diese Blue-Pill ist was ganz anderes ...

ETM FFF42003 h = 4294189059
DWT FFF02003 h = 4293926915 (Data Watchpoint and Trace)
falls korrekt ausgelesen. Was sagt das nun aus?

Meins scheint okay zu sein.. Alles okay, nur DeviceID und Revision auf 
0x000..

Ich kaufe auch gern günstig, schaue aber schon das der MCU Preis noch 
mit im Board drin ist, das ist ja gesunder Menschenverstand.

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

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.

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?

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.

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?

Karsten M. schrieb:
> Error: Debug adapter doesn't support 'swd' transport

Kannst du es noch ein mal mit der hier probieren?
Kann sein dass ich die falsche Datei erwischt hatte.

Das Bild im Flash dient ja nur der einfachen Veranschaulichung.

Mike J. schrieb:
> Kannst du es noch ein mal mit der hier probieren?

Kein Problem.

> Das Bild im Flash dient ja nur der einfachen Veranschaulichung.

Daher ist es auch witzig.
Könnte natürlich ein noch witzigeres Bild sein.

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.

https://www.vdr-portal.de/forum/index.php?thread/123572-irmp-auf-stm32-ein-usb-ir-empf%C3%A4nger-sender-einschalter-mit-wakeup-timer/&postID=1316909#post1316909

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

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

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.

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)

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

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?

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.