uC USB Speicherstick defekt - Ursache?

[Hugo (Gast)]

Guten Morgen,

in meiner uC Anwendung nutze ich einen USB Stick als Datenspeicher.
Auf dem Schreibtisch läuft der Prototyp seit fast einem Jahr fehlerfrei.

Im Gerät ist nun nach 2 Wochen der (ein anderer neuer) USB Stick 
"kaputt" gegangen.

Ich möchte jetzt herausfinden, ob es am der Firmware oder an dem 
Hardwaredesign liegt. Dazu habe ich als ersten Versuch ein Backup 
erstellen wollen.

Unter Linux kam bei dd ein i/o error, ddrescue ist nach ca. 24h mit 
0,00% recovered data fertig geworden. Lohnt es sich an der Stelle weiter 
zu forschen, sprich den dump zu analysieren, oder kann ich hier von 
einem Hardwaredefekt am USB Stick ausgehen? Dann wäre es eventuell 
meinem Design geschuldet, oder der Stick ging einfach zufällig defekt. 
Oder kann das sogar durch die FW passieren?

Wie Grenze ich die Ursache bei einem einzigen Stick weiter ein? Gar 
nicht oder? Dauertest und abwarten?

Hmm, über ein paar Worte würde ich mich freuen.

Grüße

[Hugo (Gast)]

Also, mit geht es vorerst um die Eingrenzung, welche Richtung ich 
einschlagen sollte.
- USB dump analysieren
- Firmware verdächtigen und debuggen
- Hardware verifizieren
- ...

[Hp M. (nachtmix)]

Hugo schrieb:
> über ein paar Worte würde ich mich freuen.

Zwei Geräte eins davon ok, das andere kaputt. Das reicht nicht für eine 
Statistik.
Möglicherweise auch noch unterschiedliche Kapazitäten, unterschiedliche 
Technologien, unterschiedliche Hersteller und keinerlei 
Fehlerbeschreibung.

Ich werde nachher mal versuchen im Kaffeesatz zu lesen, was man dir 
raten soll.

[olaf (Gast)]

> Wie Grenze ich die Ursache bei einem einzigen Stick weiter ein? Gar
> nicht oder? Dauertest und abwarten?

Wird der USB-Stick von Linux beim einstecken erstmal als solcher 
erkannt?

Wenn nein dann hat deine Hardware den Controller darauf zerstoert.

Wenn ja dann laeuft der Controller, aber die Daten in seinen Speichern
sind zerstoert worden.

Dafuer sind dann natuerlich wieder verschiedene Ursachen denkbar:

Zu oft beschrieben.

Versorgungsspannung unsauber oder zu frueh abgeschaltet.

Ich wuerde mal damit anfangen einen Oszi an die Spannungen zu halten.
Solche Stickes koennen ja heftig Strom ziehen. Und es kann auch
sein das sie dies nur manchmal machen.

Und natuerlich kann ein solches Fehldesign in der Spannungsversorgung 
sich auch nur bei bestimmten Sticks auswirken.

Olaf

[Achim H. (pluto25)]

Иван schrieb im Beitrag #7257351:
> Vermutlich bricht nur die Versorgungsspannung für den Stick zusammen.
> Das wiederum korrumpiert nachhaltig die Firmware des Sticks.
>
> Der Fehler sitzt also vor dem Monitor.

Nein
Da ist der Fehler die Firmeware. Ein Garantiefall.
Den neuen auf die schwarze Liste und einen anderen einsetzen.

[Stefan F. (Gast)]

Da er ddrescue ausführen konnte, wurde der Stick noch erkannt. Sein 
Controller ist nicht defekt.

Dass die Speicherchips von USB Sticks (insbesondere im unteren 
Preissegment) spontan kaputt gehen ist nicht neu. Die Nachforschung wird 
wohl kaum neue nützliche Erkenntnisse bringen.

Wie haben die gleiche Diskussion auch immer wider mit SD Karten.

[oszi40 (Gast)]

Sticks sind Verschleißteile, billige ganz besonders und wenn sie beim 
Scheiben gestört werden, ist Ärger vorprogrammiert. Man kann den Stick 
testen, bevor man ihn für wertvolle Aufgaben einsetzt. h2testw hilft.
https://www.heise.de/download/product/h2testw-50539

[Stefan F. (Gast)]

oszi40 schrieb:
> und wenn sie beim Scheiben gestört werden, ist Ärger vorprogrammiert

Ja, dann kann man sich nur noch ein Ei auf die Scheibe backen :-)

[Иван (Gast)]

> wurde der Stick noch erkannt. Sein
> Controller ist nicht defekt.

Die Firmware eines Sticks besteht aus 2 Teilkomponenten:
Im ROM sitzen die Routinen mit denen sich der Stick ueberhaupt
am USB-Bus enumerieren kann. Das muss auch so sein, weil ueber
diesen Weg die eigentliche Controllerfirmware vom Hersteller
installiert wird.

Der Schluss das der Controller nicht defekt ist, ist oder
kann daher nur "halbrichtig" sein.
Ohne die Firmwarekomponente die der Controller im Flash
speichert, tut er nicht mehr viel sinnvolles.

[Stefan F. (Gast)]

Иван schrieb:
> Ohne die Firmwarekomponente die der Controller im Flash
> speichert, tut er nicht mehr viel sinnvolles.

Ohne die hätte er das Programm ddrescue nicht ausführen können. Er hätte 
nämlich kein Laufwerk (wie /dev/sdb) gehabt.

[Иван (Gast)]

> Ohne die hätte er das Programm ddrescue nicht ausführen können.

Falsch. Der Stick meldet sich mit "0 blocks capacity".

[oszi40 (Gast)]

Hugo schrieb:
> Unter Linux kam bei dd ein i/o error, ddrescue ist nach ca. 24h mit
> 0,00% recovered data fertig geworden.

Also kaputt. Nächsten Stick vorher prüfen. Evtl. gab es beim Scheiben 
einen Spannungseinbruch am Tatort? Stütz-C ?

[Achim H. (pluto25)]

Könnte helfen. Aber da der andere lange hält war der letzte eine 
Fehlkonstruktion.
Erstaunlich wie oft Leute einen Müll verteidigen. Geräte die keinen 
Stromaufall vertragen sind einfach schrott. Es gibt ja welche die das 
Vertragen, also ist es nicht physikalisch begründet sondern schlecht 
gebaut.(fehlerhaft programmiert)

[Иван (Gast)]

> Erstaunlich wie oft Leute einen Müll
absondern der von Unkenntnis gepraegt ist.

Unter UNIX gibt es sogar einen extra "Systemcall" um ein
Filesystem in einen recht kurzlebigen *konsistenten" Zustand
zu versetzen. Kurzlebig deshalb, weil bereits der naechste
Prozess wieder auf das Medium geschrieben haben koennte.

Ich wuerde doch mal wetten, dass deine ach so fehlerfreie
Applikation gerade mal ein Open(R/W) auf eine Datei oder
mehrere Dateien macht.
Und weiter nichts.
Als da z.B. waeren:
- Flush
- Close
- Sync

Fuer USB-Geraete gibt es uebrigens eine Spezifikation in der
auch Details der Versorgung stehen. Die solltest du vielleicht
mal lesen. Auch "Billig"-Sticks haben ein Anrecht auf deren
Einhaltung.

[Иван (Gast)]

Es hat hier keinen Sinn qualifizierte Beitraege zu schreiben,
wenn die Loeschbolzen hier meinen immer alles abraeumen zu muessen.

Die anderen Beitraege bitte auch loeschen.
Abet bitte zuegig!


Na gut.
Dann wird eben nur noch gespammt.