Hallo Zusammen, ich möchte ein Eprom an meinen STM23f103 Mikrocontroller anschließen und anschließend Lesen und Programmieren. Hat jemand von euch erfahrung mit EPROM-s oder ein Bausatz dafür? Problem sind die Spannungen, da mein Mikrocontroller ein Spannungspegel von 3.3 V benötigt. Hingegen braucht der Eprom 5 Volt betriebsspannung und 25 V Programmierspannung.
Serielle EEPROMS gibts für die Spannung http://cdn-reichelt.de/documents/datenblatt/A300/MIC_11AA02E64.pdf Oder willst du wirklich ein UV löschbares EPROM verbauen ? Gruß JackFrost
Kauf dir einen Eprom Brenner. Ich glaub nicht das du für den STM da was finden wirst.
TImo schrieb: > ich möchte ein Eprom an meinen STM23f103 Mikrocontroller anschließen und > anschließend Lesen und Programmieren. Willst Du Dir einen Eprom-Programmierer selbstbauen? Wozu soll das gut sein? EPROMs sind Technik des letzten Jahrtausends, heute nimmt man Flash-ROMs, die brauchen keine abstrus hohen Programmierspannungen und können vor allem ohne ausgebaut zu werden auch wieder gelöscht werden. Mit gigantischer Kapazität gibt es Flash-ROMs spottbillig in Form von SD-Karten.
Hallo zusammen, vielen Dank! Ich brauche eine Art OTP Speicher.Flash Rom-s können gelöscht werden. EPROM auch aber nicht ohne Aufwand.
Für STM32 F100 gibt auch ein "EEPROM" SW um in das Flash zu schreiben. Schreib cyclen sind dan begrenzt auf ca 10 k, aber mit wear leveling kan das verbesseren. Nachteil : um das flash zu wischen, muss minimal ein page gewischt werden, damit braucht man immer das dobbel von "eeprom" memory.
Und wenn du das EEPROM http://www.atmel.com/Images/Atmel-5228-SEEPROM-AT25080B-160B-Datasheet.pdf#page10 "Extern" programierst und dann CS und WP zusammen legst. Ggf unter dem IC dann kann man ohne Zugriff nicht schreiben Gruß JackFrost
TImo schrieb: > Ich brauche eine Art OTP Speicher. Hmm. Und mit welcher Kapazität? EPROMs sind halt nicht besonders groß. Wobei, wenn Du Dir eins mit 25V Programmierspannung ausgesucht hast, dann kommts Dir nicht auf Größe an, das ist nämlich uralt. "Neuere" EPROMs kommen mit 12.5V aus ... Allerdings: Die Daten in EPROMs sind nicht vor dem Überschreiben gelöscht; Du kannst jedes EPROM mit Nullen überschreiben. Nur Einsen bekommst Du nicht ohne externes Löschgerät wieder hinein. Als Sicherheitsmechanismus taugt das also nicht sehr viel.
Klar das mit dem Überschreiben hast vollkommen recht!. Aber gibt es nicht ein Speicher der NUR geschrieben und nicht gelöscht werden kann?? Also die 25V hab als referenz genommen. Bastian W. schrieb: > Und wenn du das EEPROM > http://www.atmel.com/Images/Atmel-5228-SEEPROM-AT2... > > "Extern" programierst und dann CS und WP zusammen legst. Ggf unter dem > IC dann kann man ohne Zugriff nicht schreiben > > Gruß JackFrost Es muss zeit zur Zeit Datten geschrieben werden. Das heißt es muss eine Möglichkeit gefunden werden das alles vom Mikrocontroller gesteuert wird. Das habe ich im Moment gefunden: http://www.mouser.com/ds/2/36/Doc0601-16957.pdf Hier muss aber für die Programmierung VCC=6.5V und VPP=13V bereitgestellt werden.
TImo schrieb: > Aber gibt es > nicht ein Speicher der NUR geschrieben und nicht gelöscht werden kann?? TImo schrieb: > Es muss zeit zur Zeit Datten geschrieben werden. Das heißt es muss eine > Möglichkeit gefunden werden das alles vom Mikrocontroller gesteuert > wird. Schließt sich das nicht gegenseitig aus ? Oder willst du nur Anhängen ? Willst du das fertigen lassen ? Wenn ja , kannst es ja bei beidem mit BGA probieren und die /WP Leitung als Zwischenlage einer Multilayerplatine. Ist die Frage wie weit das stört wenn die auf dem GND Layer liegt. Gruß JackFrost
Bastian W. schrieb: > TImo schrieb: >> Aber gibt es >> nicht ein Speicher der NUR geschrieben und nicht gelöscht werden kann?? > > TImo schrieb: >> Es muss zeit zur Zeit Datten geschrieben werden. Das heißt es muss eine >> Möglichkeit gefunden werden das alles vom Mikrocontroller gesteuert >> wird. > > Schließt sich das nicht gegenseitig aus ? Oder willst du nur Anhängen ? > > Willst du das fertigen lassen ? Wenn ja , kannst es ja bei beidem mit > BGA probieren und die /WP Leitung als Zwischenlage einer > Multilayerplatine. Ist die Frage wie weit das stört wenn die auf dem GND > Layer liegt. > > Gruß JackFrost Also die Daten dürfen NUR einmal geschrieben werden. Löschen/Ändern ist eigentlich nicht erlaubt! Klar die Sicherheit ist aufgefordert im Rahmen der Möglichkeiten. Ich brauche ja kein neuen Speicher entwickeln. Mir geht darum einfach eine Möglichkeit zu finden wie ich den STM32f103 mit dem Eprom verbinde und Daten schreiben und zurück lesen können mehr nicht. Fertigen ja aber im Moment mach mir gedanken wie es überhaupt funktioniert. Aus dem Grund wollte mal hier im Forum nach Beispielen fragen. Für jede Hilfe bin ich sehr dankbar.
Vielleicht einer von denen? http://de.rs-online.com/web/c/halbleiter/speicherbausteine/memory-button-eprom-add-only/?searchTerm=otp+flash&h=s&sra=oss Lesen geht mit 3V, zum programmieren werden 12V benötigt. OTP bzw. "Add Only".
TImo schrieb: > Mir geht darum einfach eine Möglichkeit zu finden wie ich den STM32f103 > mit dem Eprom verbinde und Daten schreiben und zurück lesen können mehr > nicht. Also wenn Du Dich an dem klassischen EPROM vergnügen willst: Such Dir den Programmieralgorithmus raus. Schau Dir an wo was angelegt werden muss und welche Spannung Du dafür benötigst. Wenn ich das recht im Kopf habe sind das aber an irgendeinem Pin dann 7V. Schau dass Du Adressen und Daten zusammen auf einem Bus erzeugen kannst (Multiplexing) dann sparst Du PINs. Ansosnten such Dir einen andere Lösung (wie vorgeschlagen) mit EEPROM oder vielleicht "Add Only Memory": http://www.mouser.de/ProductDetail/Maxim-Integrated/DS2505P+TR/?qs=sGAEpiMZZMs6Aik9Fp479ks2Zu5YRpJxGeBv8AfdNvI%3d rgds
Macronix MX25L25635FMI-10G ist ein NOR-Flash mit Password-Schutz pro Sektor. Funktioniert mit 3.3 Volt und SPI. Gibt's im breiten SO-16 bei Digikey und Future.
TImo schrieb: > Aber gibt es nicht ein Speicher der NUR geschrieben und nicht gelöscht > werden kann?? Nicht als Halbleiterspeicher. Als optischer Massenspeicher, da heißt das dann WORM ("write once read many"), oder als Bandlaufwerk (bei LTO gibt es für diese Aufgabe spezielle Bandtypen). Aber das ist nichts, um es mit einem µC zu verbinden. Spezifiziere Deine Aufgabenstellung genauer. Wenn es um Manipulationssicherheit geht, sollte eine stinknormale SD-Karte genügen, auf der Du Dateien ablegst, die wie z.B. bei PGP mit einem Schlüssel gekennzeichnet sind. Dann können die Dateien zwar gelöscht, aber nicht verändert werden.
Schau, ob das hier nicht funktionieren würde: https://www.maximintegrated.com/en/products/digital/memory-products/DS2505.html fchk
Rufus Τ. F. schrieb: > sollte eine stinknormale SD-Karte genügen Alle SD-Karten haben einen Passwortschutz. Damit kann man die Karte komplett Sperren und gegen Lesen/Beschreiben schützen. Das ist zwar nur so sicher wie die internen Algorithmen der Karte, aber immer noch wesentlich sicherer als ein EPROM. Außerdem können die meisten SD-Karten-Leser und Smartphones den Passwortschutz onehin nicht verwenden und melden eine geschützte Karte einfach als defekt. Vom Mikrocontroller aus ist das Setzen/Senden des Passworts aber überhaupt kein Problem. Ist so wesentlich einfacher als eine echte Verschlüsselung/Signatur.
>Ich brauche eine Art OTP Speicher.
frage, wie sicher es sein muss.
evtl bei Mem- oder RAM-baustein einfach die betr Pins abschalten,
oder kleinen uC nehmen (mit EEPROM u eingebauter Seriennr), dann mit
Verschlüsselung.
Die Spec klingt, als ob jemand den TÜV im Hause hatte, ohne selbst einen kompetenten Elektroniker zugezogen zu haben. Macht nix, sowas führt manchmal zu interessanten Aufträgen. ;) Scherz beiseite, wie wäre es, das EPROM mit einem zweiten Mikrocontroller zu emulieren? Eine MCU die Ihren eigenen Flash-Speicher schreiben kann, sowie entsprechend aktivierten Firmwareschutzmaßnahmen, löst die Aufgabe. An einen F1 würde ich einen F0 hängen - selbe Entwicklungsumgebung, Hardwarekosten 0,50€. Meine bevorzugte Lösung wäre die interne EEPROM Emulation gewesen. Weiteres Aufwand rechtfertigt die bisher bekannte Aufgabenstellung nicht.
Also die Lösung scheint ein Password-Ptotected Flash memory. http://www.spansion.com/Support/Datasheets/S25FS-S_00.pdf würde aber gerne eine mit 3,3 V haben. Kennt jemand so eine Flash Memory Typ mit 3.3 V ??
TImo schrieb: > Kennt jemand so eine Flash Memory Typ mit 3.3 V ?? Dr. Sommer schrieb: > Alle SD-Karten haben einen Passwortschutz. SD-Karten laufen mit 3.3V, haben einen Passwortschutz, sind billig und leicht beschaffbar.
Dr. Sommer schrieb: > TImo schrieb: >> Kennt jemand so eine Flash Memory Typ mit 3.3 V ?? > > Dr. Sommer schrieb: >> Alle SD-Karten haben einen Passwortschutz. > > SD-Karten laufen mit 3.3V, haben einen Passwortschutz, sind billig und > leicht beschaffbar. Danke für deine Antwort. Ja das Problem ist das ich keine SD Karte benutzen darf. Es muss in die Leiterplatte intergierbar sein :-)
Wenn Du irgendwas sinnvoll schützen willst, solltest Du erstmal mit einer Bedrohungsanalyse starten bevor Du Dir über Gedanken über die Umsetzung oder konkrete Technologien wie EPROM machst. Mal ein paar Fragen dazu als Anregung: Also was willst Du vor wem/was schützen? Geht es um einen böswilligen, aktiven Angreifer oder um Schutz vor Fehlern, Störungen etc.? Wenn Angreifer: Wie ist der Angreifer ausgestattet? Was hat er für Zugriffsmöglichkeiten und wie lange? Reicht es, einen Angriff als solchen zu erkennen oder muss der irgendwie verhindert werden? Was soll dann passieren? Was für ein Schaden tritt ein, wenn der Angreifer den Schutz überwindet? Lohnt sich da ein aufwendiger Schutz überhaupt? Oder tritt ein singifikanter Schaden erst auf, wenn eine fertige Angriffsanleitung irgendwo publiziert und dann massenhaft nachgemacht wird? Was für ein Schaden tritt ein, wenn die Schutzfunktion fälschlicherweise einen Angriff erkennt (false-positive)? Oder geht es eigentlich gar nicht darum einen wirklich sinnvollen Schutz zu entwickeln, sondern es muss nur irgendeine Vorschrift/Zertifikat/Norm... mit geringstmöglichem Aufwand eingehalten werden?
Marcus H. schrieb: > Scherz beiseite, wie wäre es, das EPROM mit einem zweiten > Mikrocontroller zu emulieren? Eine MCU die Ihren eigenen Flash-Speicher > schreiben kann, sowie entsprechend aktivierten Firmwareschutzmaßnahmen, > löst die Aufgabe. Warum einen zweiten uC? Das kann der erste doch selbst? Notfalls muss man einen etwas größeren nehmen. Richtig einfach wird es mit denen, die ein zweigeteiltes Flash (Dual Bank) haben. Das wird immer noch billiger als die Hochspannungserzeugung für ein EPROM und ist sicherer. Ja, Flash kann gelöscht werden. Aber nur vom Programm auf dem Chip selbst. Alle Änderungen am Speicherinhalt passieren (nur) genau so, wie du es programmiert hast. Als Kompromiss gibt es den RDP Level 1. Dann muss der Angreifer einen Debugger anschließen (an 0.5mm Pins anlöten) und kann dann das gesamte Flash löschen, also auch das Programm. Danach hat er einen teuren Türstopper.
eagle user schrieb: > Warum einen zweiten uC? Das kann der erste doch selbst? Warum reißt Du meinen Post auseinander, wenn Du schon zitierst? Ich schrieb bereits "Meine bevorzugte Lösung wäre die interne EEPROM Emulation gewesen."
es tut mir leid, es war nicht böse gemeint. Ich hab' "Emulation" übersehen und die meisten STM32 haben ja kein EEPROM. Aber du könntest es auch positiv sehen: ich verbreite doch deine gute Idee.
TImo schrieb: > Also die Lösung scheint ein Password-Ptotected Flash memory. > > http://www.spansion.com/Support/Datasheets/S25FS-S_00.pdf > > würde aber gerne eine mit 3,3 V haben. > > Kennt jemand so eine Flash Memory Typ mit 3.3 V ?? Nimm eine Anzahl 74LVC1T45. Das löst Dein Problem. fchk
Ich fänd es wichtig, wenn zunächst mal Gerds Punkte abgearbeitet werden, bevor weiter wild Spekulationslösungen gemacht werden. Gruß Jobst
Hallo zusammen, ich bedanke mich sehr für eure Unterstützung. Hier meine Lösung: http://www.spansion.com/Support/Datasheets/S25FL127S_00.pdf Dieser Flash-Memory erlaubt "– Advanced Sector Protection (ASP) – Individual sector protection controlled by boot code or password". Das heißt bei mir wird schreiben und lesen ist nur mit einem gültigen Password möglich sein. Also zum glück brauche ich kein EPROM. Ich bedanke mich vielmals für eure Unterstützung. Gruß und schoennes WE
TImo schrieb: > http://www.spansion.com/Support/Datasheets/S25FL127S_00.pdf > Dieser Flash-Memory erlaubt "– Advanced Sector Protection (ASP) > – Individual sector protection controlled by boot code or password". > > Das heißt bei mir wird schreiben und lesen ist nur mit einem gültigen > Password möglich sein. Nun, SPI ist keine Geheim-Schnittstelle. Jeder billige Logic-Analyzer für 10 EUR kann Deinen SPI-Datenverkehr aufzeichnen und damit das Passwort mitschneiden wenn Du es an den Flashbaustein überträgst. Ich bin immer noch der Meinung daß Du erst mal ne gründliche Bedrohungsanalyse machen solltest.
Gerd E. schrieb: > Ich bin immer noch der Meinung daß Du erst mal ne gründliche > Bedrohungsanalyse machen solltest. Ich auch. Will er aber wohl nicht. Ihm reicht, wenn 'sicher' oben auf dem Baustein drauf steht. Gruß Jobst
Gerd E. schrieb: > Nun, SPI ist keine Geheim-Schnittstelle. Jeder billige Logic-Analyzer > für 10 EUR kann Deinen SPI-Datenverkehr aufzeichnen und damit das > Passwort mitschneiden wenn Du es an den Flashbaustein überträgst. Das Problem haben FPGAs ja schon immer. Die dazu passende Lösung ist, dass auf der SPI kein Klartext übertragen wird. Naja, ist doch eine schöne Sammlung geworden, was man so an Parameterspeicher an MCUs hängen kann.
Marcus H. schrieb: > Das Problem haben FPGAs ja schon immer. Die dazu passende Lösung ist, > dass auf der SPI kein Klartext übertragen wird. Naja, die Kommunikation ist schon Klartext, nur die Daten nicht. Und auch hier stellt sich die Frage, was erreicht werden soll. Die Daten im EEProm lassen sich: Kopieren (!), Löschen und -wenn auch nicht sinnvoll- überschreiben. Der einzige Angriff, der damit abgewehrt wird, ist reverse engeneering des Code. (Und auch da bin ich sicher, dass es da Möglichkeiten gibt, solange der 'Encoder' zur Verfügung steht.) Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Marcus H. schrieb: >> Das Problem haben FPGAs ja schon immer. Die dazu passende Lösung ist, >> dass auf der SPI kein Klartext übertragen wird. > > Naja, die Kommunikation ist schon Klartext, nur die Daten nicht. mmh? > Und auch hier stellt sich die Frage, was erreicht werden soll. > Die Daten im EEProm lassen sich: Kopieren (!), Löschen und -wenn auch > nicht sinnvoll- überschreiben. Ganz so einfach ist das Kopieren nicht. Aktuelle Chips haben eine eindeutige ID. Ein ordentlicher Scrambler baut auf sowas auf.
Marcus H. schrieb: > Ganz so einfach ist das Kopieren nicht. Aktuelle Chips haben eine > eindeutige ID. Ein ordentlicher Scrambler baut auf sowas auf. Und in der Massenproduktion werden dann in jedem Chip andere Daten abgelegt? Und auch die ID ist ja lesbar und somit kopierbar (mit etwas mehr Aufwand - zugegeben) Gruß Jobst
Jobst M. schrieb: > Und in der Massenproduktion werden dann in jedem Chip andere Daten > abgelegt? Mich überrascht, dass Dich das überrascht. Was für MCUs und FPGAs setzt Du denn so ein, dass Du das nicht kennst?
Ich habe mir bei Devices mit externem, seriellem EEProm noch nie Gedanken darüber gemacht. Dass die Daten verschlüsselt sind, war mir bekannt, auf welche Weise, nicht. Gruß Jobst
Schau dir mal die Atmel AT45DB011D an. Ist ein seielles Flash mit einer Funktion Namens Sector Lockdown. Wenn du dieses Register setzt, kann es nie wieder zurück gesetzt werden und es verhindert das Programmieren des entsprechenden Sektors des Speichers, somit hast du ein EPROM. Christian_RX7
PROM... ;) Der unerreicht sicherste Speicher ist immer noch das "Signetics 25120". Für aktuelle, generische Anwendungen sind "Atmel CryptoMemory" eine Idee: http://www.atmel.com/products/security-ics/secure-memory/default.aspx
Marcus H. schrieb: > Der unerreicht sicherste Speicher ist immer noch das "Signetics 25120". Brilliant finde ich im DB neben dem Wasserhahn noch das Diagramm mit den Steckzyklen und den zu erwartenden verbogenen Beinchen :-D Gruß Jobst
Jobst M. schrieb: > Und in der Massenproduktion werden dann in jedem Chip andere Daten > abgelegt? Wieder näher am Thema und warum ich die EEPROM-Emulation mit eigener Firmware bevorzuge -> Max max hat hier auch auf die harte Tour rausgefunden, wie gut moderne Schutzmechanismen arbeiten: Beitrag "Re: STM32 ST-LINK Utility Read Out Protection to level 2" Es ist nicht unmöglich an der höchsten Schutzstufe einer aktuellen MCU vorbeizukommen, es braucht aber etwas mehr Equipment und Erfahrung.
Marcus H. schrieb: > Es ist nicht unmöglich an der höchsten Schutzstufe einer aktuellen MCU > vorbeizukommen, es braucht aber etwas mehr Equipment und Erfahrung. Wenn einem dieser Schutz nicht reicht, sollte man evtl. über eine ähnliche Lösung wie bei den IBM-Cryptokarten nachdenken: Wenn die feinen in der Vergussmasse liegenden Drähtchen berührt, durchtrennt oder verbunden werden, wird der batteriegepufferte Speicher gelöscht. Gruß Jobst
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.