mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MMC/SD Adresse


Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,


Ich bin gerade dabei mich mit MMC und SD-Karten zu beschäftigen.
Die Initialisierung, das Auslesen des CID- und des CSD-Regsisters, sowie 
das Lesen und Schreiben von Blöcken funktioniert.

Beim letzteren, also beim Lesen und Schreiben, stimmen die Adressen noch 
nicht ganz. Bisher bin ich davon ausgegangen, dass bei den MMC/SDC's die 
Adresse byteweise angegeben wird. Also des erste Byte hat die Adresse 
0x00, das zwölfte 0x0b und das 100. 0x63. Da in einem Filesystem wie 
Fat16 die Adresse sektorweise angegeben wird hab ich mit gedacht, dass 
ich die Sektoradresse mit 512 multiplizieren muss um die "richtige" 
Adresse in der MMC/SDC bekomme!?

Dem Anschein nach aber stimmt dies nicht so.
Ich lasse z.B.: Daten in den Sektor 155(0x13600)schreiben. Mittels 
WinHex kann ich die Daten aber im Block 54 (0x6C00) finden. Noch 
komischer finde ich dass ich beim selben Befehl die Daten auf einer MMC 
ab der Adresse (0x6F00) finde!?

Nutzen den MMC und SDC unterschiedliche Adressaufteilungen?

Ich habe dazu beide Datenblätter studiert, konnte aber keine Angabe über 
Adressen, sowie die Codierung der Adressen im Argument des Commands 
finden.


Außerdem zeigt sich nur bei der MMC, dass wenn ich die CID (oder CSD) 
auslese und danach sofort einen Sektor lese oder schreibe ein Fehler 
auftritt. Wenn ich diese Register nicht auslese geht es ohne Probleme.
Muss ich demnach eine "Pause" zwischen Befehlen einbauen?


Danke
Hias

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht solltest du mal deinen Code zum Lesen zeigen, zumindest wäre 
mir kein Problem mit den Adressen bekannt. Wie's bei den MMCs ist kann 
ich aber nicht sagen, davon habe ich keine.
Allerdings kenne ich das Problem mit dem Lesen nach CID/CSD. Weiss aber 
nicht, was man dagegen tun kann. Als ich das mal bemerkt hatte, hab' ich 
mir dann glaub' mit irgendeinem Dummy-Befehl dazwischen geholfen. Ist ja 
egal was, sollte einfach möglichst wenig zurückliefern.

Autor: E. M a t t h i a s (hias)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal!

Der Code befindet sich im Anhang.

Hias

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich selbst habe zwar noch keine MMC/SD lib geschrieben, aber habe mal 
kurz diejenige die ich 
benutze(Beitrag "MMC/SD Karte: mmc_lib Version 2.0")
mit deiner verglichen.

uint8_t cmd[] = {0x51, 0x00, 0x00, 0x00, 0x00, 0xff};
                                                 ^^

Bei dir ist das Sechste Befehlsbyte, um einen Sektor zu lesen 0xff, bei 
Stefan Seegel's Version ist es 0x95.
Allerdings kann ich nicht erklären, was und ob dieses letze Byte 
überhaupt Auswirkungen darauf hat, wohin der Sektor im Flash auf der 
Karte geschrieben wird, aber vielleicht hilft es dir dennoch.

Ciao,
Nik

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis.
Hab im nochmal im Datenblatt nachgelesen.
Das letzte Byte ist lediglich eine Checksumme (CRC7).
Im SPI Modus ist die Kontrolle der Checksumme deaktiviert (Nur bei CMD0 
braucht man sie). Von dem her ist egal was im letzten Byte steht, 
Hauptsache das letzte Bit ist Eins. Außerdem würde ich als Response 
einen CRC Error bekommen, falls eine Checksumme berücksichtigt werden 
sollte.

Hias

Autor: Nik Bamert (nikbamert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab gerade noch etwas bemerkt: Stefan Seegel verwendet in seiner lib 
andere CMD's um blocks zu lesen/schreiben. lesen : 0x40 + 0x17 => 0x57 
und zum blockschreiben 0x40+0x24 => 0x64. Aber ansonsten fällt mir 
gerade nichts mehr auf was anders aussieht..

Nik

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Vorsicht, die CMD's sind dezimal, das Übertragungsbit($40) hex.
CMD 17(Block lesen) ist also $40+17= $51
CMD 24(Block schreiben) = $40 + 24 = $58

Fehler bei CSD lesen: hängst du auch immer schön ein Dummy an die letzte 
Übertragung(8 Takte), wenn nein, mache mal.

Viel Erfolg, Uwe

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uwe

Das mit den Dummy Bytes war wahrscheinlich die Ursache. Muss allerdings 
zwei Byte schicken, aber dann funktioniert auch das Sektorschreiben nach 
dem Auslesen der CID oder CSD.
Vielen Dank für den Hinweis!

@All

Das Problem mit den Adressen bleibt leider noch.
Wie ist der Speicher in der MMC bzw. SDC adressiert?


Hias

Autor: Marc989 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI,
ich kann mal nachschauen wie ich es bei meiner MMC (SPI) mal gemacht 
habe.
War bissl selsam mit der Adressierung aber bei mir hats dann geklappt.
Ich poste es mal hier demnächst.

Marc989

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke! Wär a tolle Sache!

Was mich verwundert ist, das Ich selben Input bei den beiden Karten 
(gleicher Befehl), verschiedene Outputs bekomme (andere Adressen im 
Speicher)

Hias

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
2 Fragen: Ist/sind die Karte(n) Formatiert? Schreibst du in eine Datei, 
oder einfach so in die Sektoren? Winhex kann, wenn ich mich recht 
entsinne, nicht alle Sektoren anzeigen (erst >32?). Wenn ich jedenfalls 
mit Fat16 arbeite finde ich alle Adressen und Sektoren an der Stelle wo 
sie hingehören. Nicht das dich Winhex austrixt.

Viel Erfolg, Uwe

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke UWE!

Ich habe beide Karten mit Fat16 (allerdings unter Windows) formatiert.
Ich lasse in den Sektor 155 schreiben.
Um die Adresse zu ermitteln schiebe ich die 155 um 9 Stellen nach links.
Damit bekomme ich 0x13600.(155*512).
Aus diesem Wert berechne ich mittels eine AND-Operation sowie einer 
Verschiebung um x Stellen die Command-Sequenz.
Die sieht dann folgendermaßen aus: 0x58,0x00,0x01,0x36,0x00,0xff

Ich erwarte nun das ich in WinHex die Dateien unter einem Offset von 
0x13600 finde. Leider tue ich das nicht, sondern die Daten befinden sich 
bei 0x6c00 (SD) und 0xF600 (MMC)

Hias

P.S.: Grade Nochmal getestet: Beide mit Fat16 formatiert und mit 
obengenannten Befehl beschrieben. Leider das selber Ergebnis.

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haha!
Ich hab eine Kleinigkeit gefunden.
Die Daten werden an der richtigen Stelle abgespeichert!
Man unterscheidet nämlich zwischen physikalischer und logischen 
Sektor-Nr.
Die Adresse in die ich schreibe ist immer die physikalische Sektor 
Nummer.
Die logische Adresse stimmt nicht mit der physikalischen überein, und 
ist wohl von Karte zu Karte unterschiedlich: meine MMC hat log (132) phy 
(155) und die  SDC log (54) phy (155).

Woher kann ich diese Abweichung beziehen.
Die steht bestimmt irgendwo im FAT, oder in der Card selber?
Bingo-> steht im Boot Sector und nennt sich HiddenSectors :)

Die Frage ist nur noch wie lese ich den Bootsector aus, ohne dass ich 
die HiddenSectors-Größe kenne?

Hias

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Also die Adressen gehen alle in Sektoren auf. $6C00 = Sektor 54
$F600 = Sektor 123. Das spricht für unterschiedlichen Offset oder sowas.
Du musst jetzt nur mal rausbekommen an welchem Sektor dein Datenbereich 
beginnt. Ich vermute mal das das für die beiden Karten unterschiedlich 
ist(Grösse,def.Sektoren?), ganz erklären kann ich es aber noch nicht, da 
müsste man MBR+PBR+Vat) sehen. Aus den dort abgelegten Daten lassen sich 
die Bereiche berechnen. Wenn du jetzt in absolute Sektoren schreibst 
werden die in Winhex natürlich auch an anderer Stelle gefunden.

Mal was anderes, hast du dir mal Root angesehen? Sind bei dir auch 
Dateieinträge in Unicode drinn? Damit kämpfe ich momentan. Die Fat16/32 
Beschreibung behandelt das Thema nur als lange Dateinahmen, es sind aber 
keine, weil die Einträge sind nur 32 Byte lang. Ich weiss jedenfalls 
nicht so richtig wie ich damit umgehen muss. Hast du da irgendwelche 
Unterlagen drüber?

Viel Erfolg, Uwe

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>>Die Frage ist nur noch wie lese ich den Bootsector aus, ohne dass ich
>>die HiddenSectors-Größe kenne?

Es gibt zwei Möglichkeiten einer Formatierung:

FAT mit MBR (Master Boot Record) und FAT ohne MBR, nur mit Bootsector 
(Volume ID)

Im physikalischen Sector 0 der Karte befindet sich entweder ein MBR oder 
ein Boot Sector.

Im MBR stehen die Einträge für die jeweiligen Partitionen, für jede 
Partition gibt es einen Eintrag, der angibt, wo die jeweilige Partition 
beginnt, also welches der 1. physikalische Sector der Partition ist -> 
der Boot Sector.

Im Boot Sector steht dann drin, wieviele Reserved Sectors usw. es gibt, 
damit läst sich alles weitere berechnen.

Wenn es keinen MBR gibt, gibt es demzufolge nur eine Partition und die 
beginnt dann im physikalischen Sector 0 der Karte.

Im Anhang eine Datei, die ich mir zusammengeschrieben habe, als ich 
gelernt habe mit FAT umzugehen und meinen eigenen C Code dafür 
zuschreiben.

Sehr hilfreich: http://www.pjrc.com/tech/8051/ide/fat32.html

@ Uwe

Kannst du mal einen hex dump posten, mit so einem Eintrag.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Muss ich jetzt unbedingt meinen Schlepptop hochfahren oder findest du es 
auch selbst in der Fat16/32 Beschreibung?
Auf jedenfall geht es im phys. Sektor 0 los(Adr.???) Da steht der 
Offset(in Sektoren) bis PBR. Den musst du zerlegen und bekommst alle 
relevanten Daten.
Übrigens x 512 = x 2 und hinten 2 Nullen drann: Offset $27(Sektoren)x2 = 
$4E + 00 = $4E00 (Das letzte Adressbyte ist also immer 00) Vereinfacht 
das Rechnen.

Viel Erfolg, Uwe

Autor: Uwe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
jetzt habe ich doch tatsache den Schleptop noch aktiviert und hänge mal 
die Root.log mit an. Lässt dich allerdings nur mit einem Hexeditor 
richtig lesen. Es sind eigentlich nur 3 Dateien drauf. test.txt, 
lösch.txt und test1.txt. Die Lösch.txt ist mit test.txt identisch nur 
eben gelöscht um die Auswirkungen in Root & Fat zu beurteilen. Wenn mir 
jemand wirklich die Unicodeinträge erklären könnte wäre, ich echt froh. 
Übrigens das ist alles unter WinXP erstellt worden.

MFG Uwe

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit UNICODE sind LFN Einträge, die nur aus einer Sequence bestehen, 
also ein 32 Byte Feld.

>>Es sind eigentlich nur 3 Dateien drauf. test.txt,
>>lösch.txt und test1.txt.

Das ist nicht ganz richtig, die Dateien heissen:
Test.txt
Lösch.txt
Test1.txt

Warum du zu jedem SFN auch einen LFN hast ist einfach zu erklären:

Du benutzt Groß- und Kleinschreibung im Dateinamen, das entspricht nicht 
der SFN Vorgabe, also wird ein LFN mit angelegt, auch wenn der Dateiname 
kürzer als 8+3 Zeichen ist.

Benutze nur Kleinbuchstaben im Namen und max. 8+3 Zeichen und du wirst 
sehen, das du auch nur SFN Einträge hast.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Michael für deine Erklärung, verstehe ich auch erstmal. Kann man 
das irgendwo nachlesen? (ich kann momentan mit SFN/LFN noch sehr wenig 
anfangen)

besten Dank, Uwe

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jetzt fällts mir wie Schuppen von den Augen LFN = Long File Name?
Wenn ja stehts bei Fat16/32.

MFG Uwe

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SFN = Short File Name
LFN = Long File Name

http://staff.washington.edu/dittrich/misc/fatgen103.pdf

Autor: E. M a t t h i a s (hias)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Michael Wolf wrote:
> Im physikalischen Sector 0 der Karte befindet sich entweder ein MBR oder
> ein Boot Sector.
>
> Wenn es keinen MBR gibt, gibt es demzufolge nur eine Partition und die
> beginnt dann im physikalischen Sector 0 der Karte.
>


Hallo zusammen.
Ich bin grad ein wenig verwirrt. Bei mir steht auf beiden Karten der 
Bootsector nicht in dem phy. 0-Sektor sondern mit einem Offset versehen.
Somit kann ich ja quasi gar keinen Offset ermitteln (Hidden Sectors).

Oder kann es sein, dass in der physikalischen Adresse auch nochmal ein 
Bootsector eingetragen ist? Meine Karte sagt allerdings das Gegenteil. 
Möglich aber das da auch ein Fehler ist...

Im Anhang findet ihr ein Abbild von Winhex und dem Bootsector.
Was sagt ihr dazu?

Hias

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
Das ist nicht Sektor0 deiner Karte sondern der PBR an Sektor??(steht in 
Sektor0) schaue dir bitte "FAT32_Know-How.txt " von oben an, da steht 
alles drinn.

MFG Uwe

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du hast ja sogar einen Pfeil auf den physikalischen Sektor gemacht.
Ist dir dabei kein komisches Gefühl gekommen wie "bin ich überhaupt in 
Sektor0" ?
Kenne mich mit Winhex nicht wirklich aus, aber evetuell ist irgendwo ein 
Häkchen versteckt wie "lese physikalischen Sektor" oder so.

Viel Erfolg, Uwe

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hias

Du öffnest in Winhex die Karte als logisches Laufwerk, demzufolge ist 
Sector 0 hier der Bootsektor, also der logische Sector 0 der gewählten 
Partition.

Öffne das Laufwerk als Physikalisches Laufwerk und du wirst sehen, das 
Sector 0 auch der physikalische Sector ist, und im dem befindet sich 
dann der MBR und die Angabe wo deine Partition beginnt. Du kannst dann 
auch die Informationen der Partition anzeigen lassen, bzw. diese öffnen.


Am wichtigsten ist es hier der Unterschied zwischen physikalischen und 
logischem Sector.
Die Karte selbst wird mit den SPI Commands immer mit physikalischen 
Sectoren (Addressen) angesprochen!
Das Filesystem, also FAT arbeitet dagegen mit logischen Sectoren!

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Vielen Dank für die Hinweise.

Gibt es den einen Hex_Editor der mir meine Karte als physikalisches 
Laufwerk anzeigt. Ich habe schon 5 durchgetestet und finde bei keinem 
diese Option...

Hias

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Winhex geht das doch.

Drücke F9 um die Disk Auswahl anzuzeigen. Bei mir gibt es dann zwei 
Tree's:

Logical Drives und Physical Media

Bei Logical Drives kannst du die Laufwerke nach Buchstabe auswählen und 
als logisches Laufwerk öffnen.

Bei Physical Media werden die Datenträger direkt geöffnet, als als 
Festplatte, CDROM oder SD Karte.

Aber auch HexWorkshop bietet die Möglichkeit physikalische und logische 
Laufwerke zu öffnen. Da über STRG-D

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.