Hat sich die FAT-Formatierung auf Windows in den letzten 3 Monaten geändert?

OP #2225972
Lesenswert?

In meiner Initialisierung der FAT auf einer microSD steht u. a. folgende 
Funktion, die das Dateisystem auf der Karte prüft. In den 5 Bytes ab 
0x54 muss ja in meinem Fall "FAT16" stehen (bei Wikipedia steht zwar, 
dass es ab 0x52 ist: 
http://de.wikipedia.org/wiki/File_Allocation_Table#Bootsektor - aber es 
hat bis heute immer funktioniert).
Heute morgen hab ich seit etwa einem Vierteljahr mal wieder meine 
microSD formatiert (als FAT), und jetzt steht das nicht mehr an dieser 
Stelle. Zumindest bekomm von der Funktion immer UNKNOWN zurück.
Mit dem Hex-Editor finde ich ab 0x36 (physikalisch als auch logisch) die 
Zeichenfolge "FAT16".
Woran kann das liegen? Da wird sich doch in 3 Monaten nichts am 
Formatierungsstandard geändert haben?
1
static unsigned char identifyFileSystem(unsigned char *buf)
2
{
3
  readSector(0, buf);
4
  fileSys = UNKNOWN;  
5
  if( (buf[54] == 'F') &&
6
    (buf[55] == 'A') &&
7
    (buf[56] == 'T') &&
8
    (buf[57] == '1') &&
9
    (buf[58] == '6'))
10
  {
11
    fileSys = FAT16;    
12
  }
13
  return fileSys;
14
}

EDIT: Ich lese gerade auf WIKI, dass bei FAT12 und FAT16 die Variante 
wie bei mir im Hex-Editor ab 0x36 steht. Warum hat es aber bisher immer 
mit 0x54 geklappt??
OP #2226119
Lesenswert?

Schudi schrieb:
> Dez. 54 = Hex 0x36
> Dez. mit Hex vertauscht?

Ok, das stimmt! Dann steht das FAT16 an der richtigen Stelle auf der 
Speicherkarte. Formatierung stimmt also. Dann muss es wohl am 
µC-Programm liegen. Das sind mir die liebsten Fehler, die einfach so 
kommen, ohne dass der Sourcecode geändert wurde...wie gesagt, hat es ja 
bis zum Formatieren heute morgen geklappt.
OP #2226212
Lesenswert?

Markus schrieb:
> @Mark
>
> Was macht du, wenn du den Eintrag 'FAT16' in buf[54] bis buf[58] nicht
> vorfindest?

Weiß jetzt nicht genau, auf was du anspielen möchtest. Hab jedenfalls im 
Debugger gesehen, dass in buf[54] bis buf[58] irgendwas wirres 
drinsteht. Das liegt daran, dass
1
readSector(0, buf)
nicht richtig arbeitet. Im Detail ist es das hier:
1
unsigned int readSector(unsigned long sector, unsigned char *buf)
2
{
3
    unsigned int count = 0;
4
  sector += sectorZero;
5
  sector *= 2;  
6
  CS_PORT_OUT &= ~CS; // Chip select ON       
7
  sendCommand(CMD17,(sector>>16)&0xFF,(sector>>8)&0xFF,sector&0xFF,0,0xFF);
8
  if(cardResponse(0x00))
9
  {
10
    if(cardResponse(0xFE))
11
    {
12
      for(count = 0; count < SECTOR_SIZE; count++)
13
      {
14
        buf[count] = spi_get();
15
      }
16
      spi_get();
17
      spi_get();
18
    }
19
  }
20
  CS_PORT_OUT |= CS; // Chip select OFF         
21
  spi_get();
22
  return count;
23
}
Ich sehe im Debugger, dass die Card-Response 0xFE nicht kommt bzw. der 
entsprechende if-Zweig übersprungen wird, sodass nichts in buf 
eingelesen wird.
Habe es aber mit zwei verschiedenen microSDs versucht...selbes Problem.
Gast #2226223
Lesenswert?

Hatte mal das Problem, dass die 5v->3V Wandlung durch Spannungsteiler zu 
hochohmig war. Zuerst gings. Nach Tagen dann nimmer. War grenzwertig. 
Hab den Spannungsteiler dann niederohmiger gemacht. Danach hatte ich nie 
mehr Probleme.
Gast #2226242
Lesenswert?

Es ist nicht erlaubt den FAT-Typ so zu bestimmen wie du es machst, darum 
funktioniert es auch nicht (immer).

Laut MS-Whitepaper geht das so:

is determined by the count of clusters on the volume and nothing else.

If(BPB_FATSz16 != 0)
    FATSz = BPB_FATSz16;
Else
    FATSz = BPB_FATSz32;

If(BPB_TotSec16 != 0)
    TotSec = BPB_TotSec16;
Else
    TotSec = BPB_TotSec32;

DataSec = TotSec – (BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) + 
RootDirSectors);

Now we determine the count of clusters:

CountofClusters = DataSec / BPB_SecPerClus;

Please note that this computation rounds down.

Now we can determine the FAT type. Please note carefully or you will 
commit an off-by-one error!

In the following example, when it says <, it does not mean <=. Note also 
that the numbers are correct. The first number for FAT12 is 4085; the 
second number for FAT16 is 65525. These numbers and the ‘<’ signs are 
not wrong.

If(CountofClusters < 4085) {
/* Volume is FAT12 */
} else if(CountofClusters < 65525) {
    /* Volume is FAT16 */
} else {
    /* Volume is FAT32 */
OP #2226281
Lesenswert?

Ok, ein Neustart des Compilers hat jetzt zumindest bei einer Karte 
geholfen. Die zweite geht aber immernoch nicht. Vielleicht sind ja auch 
die Spannungspegel ein Problem bei manchen Karten.

@Hubu: Ich hatte vorher mal die FATxx-Identifikation auskommentiert, 
weil ich wusste, dass es ohnehin FAT16 ist. Dann hat aber garnichts mehr 
funktioniert. Ich denke aber, dass das Problem nicht allein am Speicher, 
sondern eben am Compiler lag. Der macht manchmal komische Sachen.

Außerdem habe ich die Fatlib nicht selbst geschrieben. Wobei es Sinn 
macht, dass das System nicht nur allein durch diese 3 Buchstaben und 2 
Ziffern irgendwo am Anfang des Mediums bestimmt wird. Da muss ja nur mal 
ein Bit kippen oder so und alles ist im Eimer.
Gast #2226328
Lesenswert?

Vielleicht hängt es mit einer Einstellung in Deinem Compiler zusammen, 
dass er Zahlen ausschliesslich in Dez. oder Hex. interpretiert, wenn sie 
keine explizite Kennzeichnung haben und so eine Fehlinterpretation 
entsteht?
OP #2226372
Lesenswert?

Schudi schrieb:
> Vielleicht hängt es mit einer Einstellung in Deinem Compiler zusammen,
> dass er Zahlen ausschliesslich in Dez. oder Hex. interpretiert, wenn sie
> keine explizite Kennzeichnung haben und so eine Fehlinterpretation
> entsteht?

Kann ich mir nicht vorstellen, da es mit der einen Speicherkarte 
funktioniert, mit der anderen aber nicht.
Moderator Persönliche Seite #2226578
Lesenswert?

Mark M. schrieb:

> Kann ich mir nicht vorstellen, da es mit der einen Speicherkarte
> funktioniert, mit der anderen aber nicht.

Ist denn eine vielleicht größer als die andere und wird daher in
einem anderen Format initialisiert?  Wenn du das Initialisieren
unter Windows machst, dann läuft das doch alles nach dem Motto:
"Wir machen das hier schon richtig, Sie müssen nicht genau wissen,
was wir wirklich tun."
OP #2227412
Lesenswert?

Jörg Wunsch schrieb:
> Ist denn eine vielleicht größer als die andere und wird daher in
> einem anderen Format initialisiert?  Wenn du das Initialisieren
> unter Windows machst, dann läuft das doch alles nach dem Motto:
> "Wir machen das hier schon richtig, Sie müssen nicht genau wissen,
> was wir wirklich tun."

Es sind schon beide "gleich groß", also offiziell jeweils 2GB. Das ganze 
Programm läuft auf einem MSP430, also nichts mit Windows. Auf Windows 
formatiere ich die Karte nur in FAT.
Moderator Persönliche Seite #2227418
Lesenswert?

Mark M. schrieb:
> Auf Windows
> formatiere ich die Karte nur in FAT.

Ja, eben, und an dieser Stelle wird ja die Struktur festgelegt, die
auf der Karte steht.

Wenn sie gleich groß sind, ist es natürlich nicht wirklich
verständlich, warum die Struktur von heute auf morgen anders
geschrieben wird.  Andererseits, solange es in der (von MS festgelegten)
Spec für ein FAT-Filesystem liegt, kann und muss es dir egal sein.
Gast #2227434
Lesenswert?

Könnte es an der Clustergröße liegen?

Beim "normalen" formatieren in Windows (GUI) kann man ja die 
Clustergröße nicht festlegen (macht es glaub ich automatisch).
Unter der Kommandozeile geht das z.B. so:
format [Laufwerk:] /FS:FAT /A:512


Grüße

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren