Guten Morgen zusammen,
wir haben im Moment ein großes Problem in der Firma und benötigen
dringend Hilfe.
Wir verwenden einen Bootloader der sowohl auf einem STM32F103VE als auch
auf einem STM32F103ZG verwendet werden kann. Es ist die selbe HEX-Datei.
Um die relevanten Adressen festlegen zu können fragt die Software direkt
nach dem Einschalten das Device mit folgender Funktion ab.
uint32_t DBGMCU_GetDEVID(void)
{
return(DBGMCU->IDCODE & IDCODE_DEVID_MASK);
}
Normalerweise sollte folgendes zurückgegeben werden:
STM32F103VE -> 0x414
STM32F103ZG -> 0x430
Das hat bisher immer funktioniert. In letzter Zeit haben wir folgendes
Problem. Bei ca 4% der µC liefert der STM32F103VE die Device-Id 0x430
zurück. Der Bootloader meint somit es ist ein STM32F103ZG und setzt die
relevanten Adressen falsch. Den Rest könnte ihr euch dann denken.
Wenn wir uns dann mit dem ST-Link auf den µC gehen zeigt der ST-Link
auch die falsche Device-Id an. Wir sind uns mittlerweile sicher, dass
dies ein Problem im Chip ist. Jetzt zu meinen Fragen:
1) Hat von euch schon jemand ähnlich Probleme gehabt? Kann es sich
eventuell um gefakte µC handeln. Wir haben einen Funktionstest
durchgeführt und die µC scheinen bis auf das besagte Problem zu
funktionieren.
2) Wie könnte man sonst noch sicher erkennen welcher µC verbaut ist? Als
Alternative könnten wir 2 Hex-Dateien mit festen Adressen erstellen,
dass wollen wir aber, wenn es geht vermeiden.
Vielen Dank für Eure Hilfe.
Hans D. schrieb: > Wie könnte man sonst noch sicher erkennen welcher µC verbaut ist? Seit STM32F103 wie blöd in zahlreichen Varianten gefälscht werden, gibt es keine Sicherheit mehr.
Hier könnte es lohnen, die Lieferkette zu kontrollieren. Bei welchem Händler wurde die letzte Charge dieser µCs bestellt?
Harald K. schrieb: > Hier könnte es lohnen, die Lieferkette zu kontrollieren. Bei welchem > Händler wurde die letzte Charge dieser µCs bestellt? An diesem Thema sind wir gerade dran. Im Moment sieht es so aus als ob die Guten und Schlechten innerhalb einer Rolle auftreten können. Was hier die Ursache sein könnte ist uns im Moment noch schleierhaft. Hat sonst noch jemand eine Idee?
Wenn es keine Fälschungen sind: Es mag durchaus sein, dass ST nicht genug "High-density" produziert und/oder "XL-Density" zuviel und dann die größeren als kleinere gelabelt werden. Vielleicht ist es mittlerweile sogar so, dass die "High" und "XL" tatsächlich identisch sind, und nur beim Konfigurieren nach dem Test die ID nebst Flash-Größe und anderen Daten passend programmiert werden. Da die F1 mittlerweile so lange in Produktion sind, wollte ST damit möglicherweise die Zahl der Maskensätze etc. etwas konsolidieren. Was für Revisionen sind das? Und ist Inhalt des Flash size register wie erwartet?
Hans D. schrieb: > Hat sonst noch jemand eine Idee? Ja, sich mit dem Problem direkt an STM wenden und nicht auf irgendwelchen Foren „ausweinen” und nach „Lösungen” suchen – das gilt insbesondere dann, wenn man als Firma agiert und es um das eigene Kapital bzw. möglicherweise generell um einen großen Schaden geht. Die Chips könnte man noch anders unterscheiden, aber dieses Wissen behalte ich in diesem Fall für mich, da das in diesem Fall mein Firmenkapital ist.
:
Bearbeitet durch User
Gregor J. schrieb: > Die > Chips könnte man noch anders unterscheiden, aber dieses Wissen behalte > ich in diesem Fall für mich, da das in diesem Fall mein Firmenkapital > ist. Du solltest alle Deine hochnäsigen Kommentare für Dich behalten :-(
Vielleicht hilf das weiter ... https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html
Wenn man die Header vergleicht, ist stm32f103xg.h nur eine Erweiterung von stm32f103xe.h. Adressen von Peripherie, die es auch stm32f103xe.h gibt, ist nicht veraendert. Als stm32f103xe behandelt sollte, sollte ein stm32f103xg keine Probleme machen. Macht ein als STM32F103VE verkaufter Chip, der sich mit 0x430 meldet Probleme, wenn man ihn als 0x430 behandelt, aber den geringeren Speicher beachtet, dann ist das ein Problem dass mit dem Verkaeufer und ggf ST zu klaeren ist. Was sagt das "Flash size register"?
:
Bearbeitet durch User
Uwe B. schrieb: > Was sagt das "Flash size register"? Abfrage des Flash Size Registers: Adresse 0x1FFFF7E0
1 | STM32F103ZG: 1MB -> korrekt |
2 | STM32F103VE (Device-Id falsch): 768kB -> falsch |
3 | STM32F103VE (Device-Id korrekt): 512kB -> korrekt |
Hier ist erkennbar, dass auch die Flash-Size falsche Daten liefert, da der VE ja nur 512kB Flash hat.
:
Bearbeitet durch Moderator
Hans D. schrieb: > Hier ist erkennbar ... dass anhand dieser Daten die beiden Controller sicher voneinander unterscheidbar sind. Ich würde aber trotzdem mal die Lieferkette abklopfen. BTW: ich habe deine Liste mit [pre] Tags so umformatiert, dass sie auch auf Mobilgeräten lesbar ist.
Gregor J. schrieb: > Hans D. schrieb: >> Hat sonst noch jemand eine Idee? > > Ja, sich mit dem Problem direkt an STM wenden und nicht auf > irgendwelchen Foren „ausweinen” und nach „Lösungen” suchen – das gilt > insbesondere dann, wenn man als Firma agiert und es um das eigene > Kapital bzw. möglicherweise generell um einen großen Schaden geht. Die > Chips könnte man noch anders unterscheiden, aber dieses Wissen behalte > ich in diesem Fall für mich, da das in diesem Fall mein Firmenkapital > ist. Das ist hier ist ein Forum, wo es genau um solche Fragen geht. Noch nie etwas von Schwarmintelligenz gehört? Du magst es nicht glauben. Die Distris sind schon kontaktiert. So hell wie du sind andere Leute also auch schon. Deine dummen Kommentare kannst du dir einfach sparen, wenn du nichts Konstruktives zur Lösung beitragen kannst.
:
Bearbeitet durch User
Lothar M. schrieb: > Hans D. schrieb: >> Hier ist erkennbar > ... dass anhand dieser Daten die beiden Controller sicher voneinander > unterscheidbar sind. > > Ich würde aber trotzdem mal die Lieferkette abklopfen. > > BTW: ich habe deine Liste mit [pre] Tags so umformatiert, dass sie auch > auf Mobilgeräten lesbar ist. Danke für das Umformatieren. Welche Formatierung wird hier benutzt? Textile? Sicher ist erst mal gar nichts. Was wird in der nächsten Charge für eine Device-Id oder Flash-Size ausgegeben?
Hans D. schrieb: > Sicher ist erst mal gar nichts. Was wird in der nächsten Charge für eine > Device-Id oder Flash-Size ausgegeben? Das ist das Problem bei solchen hingebastelten Unterscheidungslösungen. Erster Ansprechpartner für das Problem ist dein Lieferant: er hat dir Bauteile geliefert, die sich nicht entsprechend der Spec verhalten. [OT] Hans D. schrieb: > Welche Formatierung wird hier benutzt? Textile? Es ist eine Eigenentwicklung: - https://www.mikrocontroller.net/articles/Formatierung_im_Forum Aber vor allem: die Formatierung auf PCs und Mobilgeräten sieht unterschiedlich aus.
Von kaum einem Chip gibts so viele Fäschungen wie dem STM32F103 und dem FT232RL. Beim STM würde ich allein schon aus Supply Chain Gründen auf einen neueren wie den STM32F303 umsteigen. fchk
Hans D. schrieb: > Das ist hier ist ein Forum, wo es genau um solche Fragen geht. Noch nie > etwas von Schwarmintelligenz gehört? Außer der ach-so-toll-angepriesenen Schwarmintelligenz gibt es mindestens noch so etwas wie Schwarmdummheit – vor allem an solchen Orten permanent präsent, wo ein Papagei nach dem anderen dumme Sachen einfach nachplappert. ________ > Deine dummen Kommentare kannst du dir einfach sparen, wenn du nichts > Konstruktives zur Lösung beitragen kannst. Dumm (und firmenschädlich) ist leider das, was Du momentan betreibst – statt die Probleme firmenintern zu behandeln, wird es öffentlich gemacht. Hier wird nicht nur eine Unfähigkeit der Firma – Probleme anzugehen und zu lösen – offenbart, sondern auch eine gewisse Inkompetenz und Unprofessionalität gleich auf mehreren Gebieten an den Tag gelegt. Der dadurch vergrößerte Schaden folgt noch.
:
Bearbeitet durch User
Frank K. schrieb: > Beim STM würde ich allein schon aus Supply Chain Gründen auf > einen neueren wie den STM32F303 umsteigen. Klingt vernünftig. Aber Achtung, neben den offensichtlichen Unterschieden wird beim F303 die USB Peripherie ein kleines bisschen anders adressiert, obwohl es prinzipiell die selbe hardware ist.
Lothar M. schrieb: > Hans D. schrieb: >> Sicher ist erst mal gar nichts. Was wird in der nächsten Charge für eine >> Device-Id oder Flash-Size ausgegeben? > Das ist das Problem bei solchen hingebastelten Unterscheidungslösungen. > > Erster Ansprechpartner für das Problem ist dein Lieferant: er hat dir > Bauteile geliefert, die sich nicht entsprechend der Spec verhalten. > > [OT] > Hans D. schrieb: >> Welche Formatierung wird hier benutzt? Textile? > Es ist eine Eigenentwicklung: > - https://www.mikrocontroller.net/articles/Formatierung_im_Forum > > Aber vor allem: die Formatierung auf PCs und Mobilgeräten sieht > unterschiedlich aus. Wie schon oben erwähnt sind die Distris bereits informiert. Was soll hier hingebastelt sein? Es wird eine Adresse abgefragt, die laut Reference-Manual den Device-Identifier beinhaltet. Du kannst ja nicht von Anfang an davon ausgehen, dass hier ein falscher Wert zurück geliefert werden könnte. Natürlich kann man alles Zig-Mal absichern. Aber dabei gibt es mindestens zwei begrenzende Faktoren "Zeit" und "Speicher".
Sherlock 🕵🏽♂️ schrieb: > Frank K. schrieb: >> Beim STM würde ich allein schon aus Supply Chain Gründen auf >> einen neueren wie den STM32F303 umsteigen. > > Klingt vernünftig. Aber Achtung, neben den offensichtlichen > Unterschieden wird beim F303 die USB Peripherie ein kleines bisschen > anders adressiert, obwohl es prinzipiell die selbe hardware ist. Das ist in der Realität auch nicht so einfach. Unsere Kunden verlangen von uns eine Requalifizierung sobald sich auf der Leiterplatte etwas ändert, das bedeutet EMV-Prüfungen, ... nochmals neu durchführen. Und das bei einer Vielzahl von Projekten. Da macht kein Kunde mit.
Hans D. schrieb: > Was soll hier hingebastelt sein? Die Abfrage der im Datenblatt spezifizierten ID ist keine Bastelei. "Hingebastelt" wäre das (für manchen augenscheinlich naheliegende) Verknüpfen der falschen ID mit der falschen Speichergröße als "Alternativmerkmal" für einen bestimmten Typen. Hans D. schrieb: > Da macht kein Kunde mit. Dann muss er den höheren Preis für die "selektierten" µC berappen. Hans D. schrieb: > die Distris Ihr habt mehrere Bezugsquellen? > bereits informiert. Lass hören, was da rauskommt.
Bringe das Problem mal auf https://community.st.com, am besten mit Photos von den Labeln der Rollen.
Andreas B. schrieb: > Wenn es keine Fälschungen sind: Es mag durchaus sein, dass ST nicht > genug "High-density" produziert und/oder "XL-Density" zuviel und dann > die größeren als kleinere gelabelt werden. > > Vielleicht ist es mittlerweile sogar so, dass die "High" und "XL" > tatsächlich identisch sind, und nur beim Konfigurieren nach dem Test die > ID nebst Flash-Größe und anderen Daten passend programmiert werden. Da > die F1 mittlerweile so lange in Produktion sind, wollte ST damit > möglicherweise die Zahl der Maskensätze etc. etwas konsolidieren. Was > für Revisionen sind das? Und ist Inhalt des Flash size register wie > erwartet? Ich würde vorerst ausschließen, dass ST da ein Problem hat. Die bauen definitiv in mehrere Produkte, dieselben Dies ein und ich hatte da noch nie Probleme bei meinen STMs von mouser / digikey. CubeMX hat auch Jahre lang (keine Ahnung ob immernoch. Nutze es nicht) falsche Linkerskripte generiert, in denen RAM verwendet wurde, der offiziell in den Controllern teilweise gar nicht existiert. Das hat nur funktioniert, weil ST immer den größten RAM auf dem Die hat und den nicht kaputt fused. Siehe: Beitrag "SRAM Lücke STM32Fxxx, Linkerskripte falsch" Ich habe beruflich mit ST als foundry Service gearbeitet. Die haben ihr Testzentrum schon im Griff. Wenn ein Bauteil mit einer bestimmten Teilenummer produziert wird, ist das in der ganzen Testkette bekannt. Sprich, es wird nicht einfach ein Mikrocontroller gebaut und dann im Nachhinein als ein kleinerer umgelabelt. Das Testprogramm weiß schon in der Produktion, welche Typnummer der Chip hat und brennt alles richtig. Außerdem prüft in der Regel der Gurter jedes Teil nochmal nach, ob die Seriennummern etc stimmen bevor es in den Gurt gepackt wird. Würde also zu 95% auf Fälschungen tippen. Je nachdem wie groß ihr seid, kannst du ja einfach mal direkt bei ST fragen. Das Gehäuse zu öffnen bringt meistens leider nicht so viel, wenn man nicht tiefer reinschauen kann. Oft sind die Klone sehr ähnlich oder sogar mit geklauten Maskensätzen Layout identisch. Da kann man dann nur mit einer Elektronentomographie oder nem detailierten Seitenschliff rausfinden, ob das ein originaler ST-Prozess oder ein Klon ist.
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.