Gibt es für dem Micron-SPI-Flash mit 512Mbit oder 1Gbit (MT25TL01G oder MT25TL512) entsprechende Treiber (Quellcode)? Auf der Micron-Seite finde ich zwar: "MT25T Low-level device driver" https://www.micron.com/advanced-search?q=MT25T%20device%20driver Die sind aber durch ein "Schloß-Symbol" gekennzeichnet. Andere Downloads haben ein offenes Schloß. Wenn man dort hoch klickt kommt man zu einem "Document Request Form", da trägt man dann vor allem Zeiten ein (design-winow, production ramp, monthly quantity). Auch noch einen Controller Hersteller, den Form-Faktor des Speichermoduls und ob man eine NDA unterzeichnet hat. Eine NDA habe ich nicht unterzeichnet. Ich habe das innerhalb der letzten Woche schon zwei mal losgeschickt, aber es kommt einfach keine eMail bei mir an. (habe auch den SPAM-Ordner geprüft) Generell habe ich von Micron noch gar keine automatisch generierte eMail bekommen. Auch die Aktivierung des Accounts funktionierte nur mit eMail-Kontakt zum Service-Team der Seite. Gibt es anderen fertigen Code für den MT25TL SPI-Flash, den ich nutzen könnte?
Wozu (und für welches Zielsystem denn auch) sollte ein "Treiber" da wohl gut sein? Das sind doch ganz normale SPI-Flash-Chips (nur dass halt zwei in einem Gehäuse stecken) ...
A. B. schrieb: > Wozu (und für welches Zielsystem denn auch) sollte ein "Treiber" da wohl > gut sein? Naja, wenn man kein Ahnung hat dann ist eben (fast) alles ein Problem.
Richtig, der TO weiß ja offenbar noch nicht einmal, wofür er diesen ominösen Treiber braucht. Und klar, Micron stellt natürlich für alle und jeden uC/OS/Programmiersprache einen Treiber zur Verfügung. Schöne Weihnachten ...
Ich würde den SPI-Flash nur als einen Ringbuffer nutzen, damit wäre dann auch die Speicherzellenabnutzung recht gleichmäßig und man müsste sich nur noch überlegen wie man defekte Blöcke markiert um sie zu überspringen. Für "alle" Programmiersprachen muss es ja nicht sein, nur die Funktionalität ist wichtig, die Nutzung der Peripherie (SPI) der jeweiligen Controller ist nur anders und muss entsprechend angepasst werden. Für den "N25Q" gibt es ja Beispiel-code in C. Es wäre nur schön wenn man nicht alles selbst schreiben muss.
Sooo schwer ist das nun auch nicht zu implementieren. Die ganzen Flash-Bausteine unterscheiden sich gefühlt sowieso weniger im Befehlssatz und im prinzipiellen Aufbau, sondern eher in der Sektor-/Block-/Gesamtspeichergröße. Ich habe dir mal meine extflash.c angehängt, die zwar für ein deutlich kleineres Kaliber geschrieben ist, aber vielleicht als Ansatzpunkt reicht. Zum Verständnis gibt´s die spi.h noch dazu ;)
Max G. schrieb: > Ich habe dir mal meine extflash.c angehängt, die zwar für ein deutlich > kleineres Kaliber geschrieben ist, aber vielleicht als Ansatzpunkt > reicht. Zum Verständnis gibt´s die spi.h noch dazu ;) Danke, das hilft mir schon! Das Ganze soll auf einen Chip von Texas Instruments, denn Rest werde ich anpassen und erweitern. Das "Command Set" ist ja etwas größer. Eine Frage hätte ich noch. Wie würdest du fehlerhafte Sektoren markieren? Bei dem FLash-Speicher gibt es diese "SECTOR PROTECTION Operations". Der 1Mbit Chip hat 2048 der 64kByte Sektoren, man könnte bei einem erkannten Fehler den ganzen Sektor mit einem Schreibschutz versehen. Alternativ könnte ich einen Teil des Flash-Speichers (512bit) nutzen um jeweils eine "page mit 256byte" als fehlerhaft markieren zu können. Oder man könnte in das "Dedicated 64-byte OTP area (outside main memory)" schreiben. 100k Schreibzyklen sind zwar nicht wenig, aber irgend ein Schutz wäre nicht verkehrt.
Mike J. schrieb: > Wie würdest du fehlerhafte Sektoren markieren? Wie willst Du fehlerhafte Sektoren erkennen? Ein defekt äußert sich ja nicht nur dadurch, daß direkt nach dem Schreiben die Werte nicht mehr korrekt auslesbar sind. Es ist nicht unüblich, daß der Fehler sich dadurch äußert, daß die Werte erst über den Zeitraum von ein paar Minuten bis Stunden/wenige Tage kippen. Das Ding ist ja NOR-Flash, die sind lang nicht so empfindlich wie NAND. Wenn es wirklich um viele Schreibzugriffe geht, würde ich Prüfsummen in den einzelnen Sektoren vorsehen. Wenn Du das als Ringpuffer verwendest, ist die Anzahl der Schreibzugriffe gleichmäßig. Wenn jetzt einmal irgendwo die Prüfsumme nicht mehr stimmt, würde ich den ganzen Flash-IC als defekt ansehen und auf Störung gehen. Denn wenn der eine Sektor anfängt Mist zu bauen, wird es bei gleichmäßigem Schreiben nicht lange dauern bis der nächste auch ankommt. Da Du das nicht unbedingt sofort bemerkst (siehe oben) ist Datenverlust wahrscheinlich. Ein Ausklammern defekter Sektoren macht da meiner Meinung nach nicht viel Sinn.
Wir kennen die Anwendung nicht, vielleicht reichen ihm 100k Zyklen ja tatsächlich nicht. Als Anregung: jeden Sektor nach dem Schreiben mit einer CRC schützen, um fehlerhafte Daten zu erkennen. Das erste Byte im Sektor kannst du jeweils als Statusbyte nutzen, z.B. FF = ungeschrieben, F0 = teilweise geschrieben, A0 = komplett geschrieben, 00 = defekt. Du kannst aber auch mehr Aufwand treiben: Vorwärtsfehlerkorrektur (z.B. Faltungscode) einsetzen, einzelne Bitfehler können dir dann schlicht egal sein. Wenn es ganz aufwändig werden soll und du Angst vor komplett defekten Blöcken hast, kannst du auch per Interleaving die Bits jedes Bytes in verschiedene Sektoren schreiben.
:
Bearbeitet durch User
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.