Hi ich frage mich die ganze Zeit und auch schon länger, wie man in einer Die / Maskrom eine UID einbrennen kann. Wenn dieses grosse Die erstellt wird, wird dann tatsächlich an einer Stelle des jeweiligen SoC oder IC oder dergleichen, eine andere Schaltung gebrannt, die eine UID später erzeugen? Und das nächste Die? Enthält dann wieder eine andere Maske? Die UID wird bereits bei der Planung des Die und damit den einzelnen ( wie nennt man das Einzelteil? )SoC / IC oder dergleichen Kann man solche "Einbrennungen" ( mir fehlt der Fachbegriff dafür ) später an einer Stelle des Fertigunsprozesses einer "corrigere" Routine unterziehen? Warum auch immer. lg rudi ;-)
user schrieb: > Die UID in einem µC wird meistens über ein (E)(E)PROM realisiert. Das wäre aber nicht gut da überschreibar, zumindest löschbar oder zerstörbar? Beitrag "Re: Warum EEPROM nur 100.000 mal beschreibbar"
Es gibt da OTP-Zellen (one-time programmable), die werden für sowas genutzt. Klar, zerstören kannst du immer alles. ;-) Hilft das irgendwie in der Sache? Masken-ROM macht niemand unter ein paar Hunderttausend Bauteilen mit völlig gleichem Bitmuster. Vermutlich wird sowas am ehesten noch entweder für ganz billige Massen-Controller genutzt oder für sowas wie Bootloader.
würde mich nicht wundern wenn das beim belichten gleich mitgelasert wird... bei billigen/einfachen chips wo keine Funktionskontrolle (oder bloß Stichproben) vorgesehen sind rechnet sich OTP wohl nicht.
Jörg W. schrieb: > Klar, zerstören kannst du immer alles. ;-) Hilft das irgendwie in der > Sache? > > Masken-ROM macht niemand unter ein paar Hunderttausend Bauteilen mit > völlig gleichem Bitmuster. Vermutlich wird sowas am ehesten noch > entweder für ganz billige Massen-Controller genutzt oder für sowas > wie Bootloader. Jörg vielen Dank! Kannst du dir das mal ansehen? Beitrag "Re: ESP8266 einzelne Code Funktion ziehen (ASM) rboot" Der ESP hat im ROM an der Stelle seine ID sitzen. ( idapro) Ginge es - theoretisch! - die UID zu zerstören oder gar zu verändern? Mich hat der Beitrag bissal nachdenklich gemacht: Beitrag "Re: Warum EEPROM nur 100.000 mal beschreibbar" Aber wie könnte man an denen Adressen die Spannung erhöhen? ( ich höre dein Lachen bis hier her ! ;-) ) Ist das jetzt sicher ( UDI ) oder eher "..wenn der Tag kommen muss dann kommt er auch". lg rudi ;-)
Jörg W. schrieb: > Es gibt da OTP-Zellen (one-time programmable), die werden für sowas > genutzt. Sorry ( push# ) heisst das, dass man "auch erst" zu einem späteren Zeitpunkt diese OTP Zellen ( SoC wurde zgeschnitten ) im Werk 'programmieren' kann und auf dem Die noch gar nichts machen kann / noch nichts machen muss? Wie sieht sowas aus? Schickt man bestimmte Befehle an bestimmten Pins nach einem bestimmten Takt? Oder kann man sich das Vorstellen, dass der Bootloader auch solche Befehle "einmalig" oder mehrmalig entgegennehmen kann und die OTP Zellen nur ursächlich einrichten bzw auch in einem Edit Mode editieren kann? Danke! lg ;-)
"Es existieren jedoch auch "unechte" OTP-Speicher, welche als sog. "OTP-Area" in bestimmten Flash-Speichern implementiert sind. Diese Speicherbereiche bestehen in der Regel aus normalen Flash-Zellen, welche durch eine Zusatzlogik gegen Veränderung gesichert werden" Das sagt wiki noch dazu. "Einzelne OTP-Bereiche existieren auch in bestimmten Bauelementen, wie beispielsweise Flash-Speichern, Smartcards und Mikrocontrollern, wobei diese dazu dienen, Seriennummern oder andere Identifikationsdaten unabänderlich zu speichern. Ein Beispiel dazu ist die IMEI der meisten modernen Handys." Ok - wie kann man das prüfen ob es sich um echte oder unechte handelt? Gibt es ein Verfahren? lg ;-) https://de.wikipedia.org/wiki/One_Time_Programmable
Mögliche Variante wäre auch noch simples (Anti-)Fusing https://en.wikipedia.org/wiki/Antifuse#Antifuses_in_integrated_circuits Und ja, das wird im Werk direk auf dem Die gemacht, vorstellbar bspw. beim testen noch im Waferverbund.
bekannt schrieb: > Mögliche Variante wäre auch noch simples (Anti-)Fusing > > https://en.wikipedia.org/wiki/Antifuse#Antifuses_in_integrated_circuits > > Und ja, das wird im Werk direk auf dem Die gemacht, vorstellbar bspw. > beim testen noch im Waferverbund. Danke! Es geht u.a. auch darum: Der ESP hat eine UID ( DiskOnChip ) Der kann aber auch zusätzlich noch eine Companion ID erhalten, d.h. Viele SoC's haben dann eine gleiche ID, die einem Modul Hersteller, Unit Hersteller.. zugeordnet werden. Meine Überlegung war dann, wenn zur Herstellung nicht bekannt ist, wieviele SoCs ein Modulhersteller abnimmt, wie kann "espressif" wissen, wieviele sie dann mit der gleichen Companion ID "bestücken" muss? Mein erster Gegengedanke war dann, dass diese Die / Wafer dann erst hergestellt wird, wenn es einen "Companion" Käufer gibt. Wenn es im Waferverbund so geht, dass man eine bestimmte Anzahl dann auf diesem Wafer dem einen zuteilt, einen anderen Abschnitt einen anderen usw., dann ok Aber die Sache ist die, dass es anscheinend geht, wenn Module bereits auf dem Markt sind, dass diese mit einer Companion ID versehen werden können, kann es mir aber nicht vorstellen; denke eher dann ab Werk auf dem Wafer?. lg ;-)
r_u_d_i schrieb: > Der ESP hat im ROM an der Stelle seine ID sitzen. Ja, und? Warum nicht? Du kannst dir auch einen Dallas^H^H^H^H^H^HMaxim Onewire-Button kaufen, der hat auch eine eindeutige Seriennummer. Trotzdem macht sich für die paar Cent kein Hersteller die Mühe, jedem Chip seine eigene Maske zu generieren. Ob man die nun in einen Speicherbereich abbildet oder über irgendeinen Bus abfragen kann, ist doch dabei völlig schnuppe. r_u_d_i schrieb: > Ok - wie kann man das prüfen ob es sich um echte oder unechte handelt? Die Ansteuerlogik weiß das. Die entsprechenden Zellen lassen sich nur während des Fertigungstests programmieren und werden am Ende des Tests gegen weitere Schreibzugriffe verriegelt. (Das kann man durchaus brutal machen, indem sich beispielsweise im entsprechenden Block gar keine Programmierspannung mehr anlegen lässt.) Klar könnte man die ganz theoretisch irgendwo auf Bitebene wieder löschen, genauso wie du in irgendwelchen Hinterhof-Laboren für hinreichend viel Geld halt die Lockbits eines AVRs löschen lassen kannst. Der Dreh- und Angelpunkt ist, dass der Aufwand dafür höher sein muss als der Nutzen, den du aus solcherart Aktion ziehen kannst. Solange du damit dein AVR-Programm sicherst, mit dem jemand anders sowieso bloß kein Geld verdienen wird, ist das egal. Wenn du eine EC-Karte bauen willst, solltest du besser gesicherte Technologien benutzen.
r_u_d_i schrieb: > Der ESP hat eine UID ( DiskOnChip ) quatsch ;-) eine ChipID wollte ich schreiben :) mit dem DiskOnChip hab ich vor paar Minuten hantiert, so ein 'Gedankenüberschlag', da wurden benachbarte Zellen nicht ausreichend gelöscht ;-)
Jörg W. schrieb: Vielen Dank Jörg! Ok soweit verstanden. Werde mich da in die Richtung noch vertiefen. > Wenn du eine EC-Karte bauen willst, solltest du besser gesicherte > Technologien benutzen. Ein Payment Dienstleister will den SoC einsetzen, wie was wer ist noch nicht im Detail bekannt - solange die FW aber über aussenstehende Speicher abgewickelt wird, ist das alles nicht so sicher. Das ist das Manko beim ESP. Es gibt zwar Ansätze, aber letztendlich ist die FW ausserhalb. :( HW Crypt ist unbeschrieben, undokumentiert, aber vorhanden. lg ;-)
r_u_d_i schrieb: > Das wäre aber nicht gut da überschreibar, zumindest löschbar oder > zerstörbar? > Beitrag "Re: Warum EEPROM nur 100.000 mal beschreibbar" ICh gehe davon aus dass das dann im gleichen prozess gemacht wird wie auf den restlichen Chip. Also entweder Flash, EEPROM oder Fuse. Die Chips der Prozessoren werden auch über spezielle Zugriffsmöglichkeiten selektiert und dann evtl sogra umkonfiguriert: Wennd as Flash eine Produktionsfehler hat, wird der Chip dann halt mit 64k anstatt 128k verkauft, wenn der AD nicht sauber geht dann in der Vaiante ohne AD). Dazu benötigt der Hersteller Zugriff auf Parametriermöglichkeiten, vermutlich über das JTAG-Interface. In ddiesem Zuge wird dann auch eien "seriennumemr" oder "User-ID" oder wie man das auch nenne will geschrieben. Bei OTP gehe ich davon aus dass das ähnlich realisiert wird. Da steckt aber heute meist ein (E)EPROM oder FLASH-Prozess hinter den Zellen. Der Content wird dann halt schon ab Werk geflasht/programmiert. Die Zeit des wirklichen MASK-ROM ist meines Wissen bereits schon mindestens 10 Jahre vorbei. G. H. schrieb: > würde mich nicht wundern wenn das beim belichten gleich mitgelasert > wird... Halte ich für zu viel Aufwand, dann einfacher mit programmierbaren Zellen und die beim Die-Test mitprogrammieren. r_u_d_i schrieb: > Ginge es - theoretisch! - die UID zu zerstören oder gar zu verändern? Latürnich nur wenn Du weißt wie der Hersteller da ran kommt. Mir sind aber keine Dokumente irgendwelcher Hersteller öffentlich bekannt wie man an solche Bereiche rankommt. Kann mir auch vorstellen dass das, bevor die geschrieben werden, einfach geht, nach dem Beschreiben aber eine Sicherung geschossen wird damit das nicht mehr zugreifbar ist. rgds
6a66 schrieb: > Die Zeit des > wirklichen MASK-ROM ist meines Wissen bereits schon mindestens 10 Jahre > vorbei. Ich könnte mir vorstellen, dass es bei einigen fernöstlichen Produkten in Millionenstückzahlen noch eine Rolle spielt. Vermutlich sind auch fest eingebaute Bootloader (U-Boot etc.) noch als Maske implementiert. > Kann mir auch vorstellen dass das, bevor > die geschrieben werden, einfach geht, nach dem Beschreiben aber eine > Sicherung geschossen wird damit das nicht mehr zugreifbar ist. So ist es. Die Teile nennen sich auch im Herstellerjargon OTP, d. h. nachdem sie einmalig auf dem Tester programmiert worden sind, lassen sie sich selbst mit Kenntnis der Hersteller-Interna nicht noch einmal umprogrammieren.
Jörg W. schrieb: >> Die Zeit des >> wirklichen MASK-ROM ist meines Wissen bereits schon mindestens 10 Jahre >> vorbei. > > Ich könnte mir vorstellen, dass es bei einigen fernöstlichen > Produkten in Millionenstückzahlen noch eine Rolle spielt. Vermutlich > sind auch fest eingebaute Bootloader (U-Boot etc.) noch als Maske > implementiert. Ja, das denke ich auch, und zwar insbesondere bei solchen Bausteinen für Türklingeln, Glückwunschkarten und allereinfachste Armbanduhren. Ich kann mir vorstellen, dass Masken-ROMs aber auch für die Bootloader und Initalisierungsfunktionen in Satelliten eingesetzt werden. Dort hat man ja gewaltig mit kosmischer Strahlung zu kämpfen. Die eigentliche Firmware kann dann ja redundant in mehreren Flashes gespeichert sein, wobei der Bootloader nur Firmware mit einwandfreier Prüfsumme anspringt oder ins RAM kopiert. Die klassischen OTP waren übrigens meist EPROMs ohne Fenster. Dadurch konnte man wesentlich billigere Gehäusematerialien wählen. Solche OTPs hatten dann auch keinen Veränderungsschutz, sondern man konnte auch später noch mit Hilfe der EPROM-typischen Programmierspannungen (25V/21V/12,V) die Bits in eine Richtung (meist 1->0) umklappen. Mir ist nicht bekannt, ob es auch OTPs mit 0->1 gab, denn diese Programmierrichtung war ja nur bei den allerersten (P-MOS?) EPROMs gebräuchlich. Völlig OT: Beim Z80 hatte NOP die OP-Code 0x00 und RST38 den OP-Code 0xff. Um zu erkennen, dass ein Programm in einen nicht programmierten EPROM-Bereich gesprungen/abgestürzt war, brachte man gelegentlich an Adresse 0x0038 eine passende Auffangroutine unter.
6a66 schrieb: > Die > Chips der Prozessoren werden auch über spezielle Zugriffsmöglichkeiten > selektiert und dann evtl sogra umkonfiguriert: Wennd as Flash eine > Produktionsfehler hat, wird der Chip dann halt mit 64k anstatt 128k > verkauft, wenn der AD nicht sauber geht dann in der Vaiante ohne AD). Oder noch übler: einige Hersteller machen sich nicht einmal die Mühe, teilweise defekte Bausteine durch Konfigurationsbits zu kennzeichnen oder gar Funktionsblöcke zu deaktivieren. Ein Beispiel hierfür ist das Paar LPC2214/LPC2294. Erstgenannter hat "keinen" CAN-Controller, letzterer vier Stück. Dennoch findet man bei beiden die entsprechenden Register. Vielleicht geht es dabei aber auch nur um die Fälligkeit von Lizenzzahlungen für die CAN-Blöcke. Das ganze kann zu ziemlich schwer auffindbaren Fehlern führen, wenn man nämlich einen zu generischen Bootloader hat, der auf blauen Dunst alle Peripherieblöcke einer Bausteinfamilie initialisiert und dabei ggf. einen defekten Block aktiviert, der zu Störungen führt. So etwas passiert auch bei Bausteinen, die auf dem Chip viel mehr Peripherie haben als an den Gehäusepins nach außen bereitgestellt. Fehlende Pull-Up/Down-Widerstände führen dann durchaus zu unerwünschten Interrupts oder gar zu einer viel zu hohen Leistungsaufnahme. Bekanntes Beispiel: Atmel AT91RM9200. Bei dem Prozessor ist im QFP-Gehäuse nur ein USB-Host-Anschluss herausgeführt, im BGA hingegen zwei. Leider kann man Interrupts nur für beide Ports gemeinsam konfigurieren, da sie an einem gemeinsamen Root-Hub hängen. Wenn man sich die Dies von RAMs oder Flash-Bausteinen anschaut, sieht man häufig auch eine ungerade Anzahl von Speicherkacheln, z.B. fünf statt vier. Hier dient in der Tat eine Kachel als Ersatz für Defekte und wird während des Fertigungstests fest konfiguriert.
Andreas S. schrieb: > Vielleicht geht es dabei aber auch nur um die Fälligkeit von > Lizenzzahlungen für die CAN-Blöcke. Oder einfach nur Preispolitik: der Chip ohne CAN wird billiger verkauft, um die entsprechende Kundschaft anzulocken. Solange aber davon keiner Millionenstückzahlen ordert, lohnt es einfach nicht, tatsächlich einen kleineren IC zu gießen, da die Einstandskosten viel zu hoch wären. Allerdings kannst du dich als Kunde natürlich nicht drauf verlassen, immer und in alle Ewigkeit mit dem billigeren Chip bereits deine gewünschte Funktionalität zu bekommen. Außerdem wird bei dem, für den die Funktionalität nicht garantiert ist, diese auch gar nicht erst getestet (was zu einer nicht unwesentlichen Kosteneinsparung beiträgt, er wird also nicht nur billiger verkauft, sondern ist dann für den Hersteller auch tatsächlich billiger).
r_u_d_i schrieb: > r_u_d_i schrieb: >> Der ESP hat eine UID ( DiskOnChip ) > > quatsch ;-) > > eine ChipID wollte ich schreiben :) > mit dem DiskOnChip hab ich vor paar Minuten hantiert, > so ein 'Gedankenüberschlag', da wurden benachbarte Zellen nicht > ausreichend gelöscht ;-) So eine Chip-ID wird normalerweise mit Fuses gemacht, weil EEPROM und Flash zusätzliche Fertigungsschritte verlangen, also mehr Kosten. Bei Fuses werden im Prinzip einfach nur Vias durchgebrannt. Von daher ist eine Chip-ID auch später veränderbar, wobei gebrannnte Vias eben schon durch sind und nicht wieder geheilt werden können. Die Chip ID wird dann in der Regel auf dem Wafertester mit gebrannt und dann auch gleich getestet. Das kann im Prinip auch im fertigen Chip gemacht werden, das Problem ist, dass der Pin für die Programmierspannung normalerweise nicht am Gehäuse anliegt, sondern nur am Die. Man kommt da also nicht dran. Kann aber auch sein, dass die die Programmierspannung intern genrieren, dann würde das auch im fertigen Chip gehen. Halte ich aber für unwahrscheinlich, denn das kostet extra Aufwand/Geld. Gruss Axel
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.