Windows und Linux lesen SD Karte falsch

>Es wurden also neue
>"Verzeichnisse" angelegt, mit den Daten als Namen, die in Windows aber
>nicht zu sehenh sind.

Die Daten wurden an die falsche Stelle geschrieben.
Klarer Fall von Fehler in der Software.

@Uhu: Was bringt es mir die Karte mit Tiny Hexer anzuschauen? Ich kann 
da nichts erkennen.

@Holger: Hier ist mein Programm, vielleicht siehst du ja einen Fehler.

1

//Hauptprogramm

2

int main (void)

3

{

4

  //Initzialisierung der seriellen Schnittstelle

5

  IOInit();

6

7

  //öffnet einen kanal für printf

8

  stdout=&mystdout;

9

10

  //Initialisierung der MMC/SD-Karte

11

  printf ("System OK\n\n");  

12

  while ( mmc_init() !=0) //ist der Rückgabewert ungleich NULL ist ein Fehler aufgetreten

13

    {

14

    printf("** Keine SD Karte gefunden!! **\n");  

15

    }

16

  printf("Karte gefunden!!\n");  

17

  fat_cluster_data_store();//laden Cluster OFFSET und Size ins EEPROM

18

  //Initialisierung der MMC/SD-Karte ENDE!

19

  unsigned char Buffer[512];

20

  unsigned char test[512];

21

  for (int i=0;i<sizeof(test);i++)

22

  {

23

    test[i]=0;

24

  }

25

  unsigned int tmp;

26

  mmc_read_csd (Buffer);

27

  //Ausgabe des Root Directory

28

  unsigned int Clustervar;

29

  unsigned char Dir_Attrib = 0;

30

  unsigned long Size = 0;

31

  for (char a = 1;a < 240;a++)

32

  {

33

    Clustervar = fat_read_dir_ent(0,a,&Size,&Dir_Attrib,Buffer);

34

      if (Clustervar == 0xffff)

35

      {

36

        break;

37

      }

38

    tmp = (Size & 0x0000FFFF);

39

  }

40

  Clustervar = 0;//suche im Root Verzeichnis

41

  printf("FERTIG!!\n");

42

  strcpy((char*)test,"0123456,2546,1256,1544,15454,254584,1254,2412,54");

43

44

 {

45

 if (fat_search_file((unsigned char*)"Daten.txt",&Clustervar,&Size,&Dir_Attrib,Buffer) == 1)

46

      {  //Lese File

47

        printf("Beschreibe File, bitte warten!\n\r");

48

        fat_write_file(Clustervar,test,0);

49

        printf("Datei erfolgreich beschrieben\n\r");

50

51

      }

52

      Clustervar = 0;//suche im Root Verzeichnis

53

      if (fat_search_file((unsigned char*)"Daten.txt",&Clustervar,&Size,&Dir_Attrib,Buffer) == 1)

54

      {

55

        printf("Lese File, bitte warten!\n\r");

56

        for (int b = 0;b<1;b++)

57

        {

58

          fat_read_file (Clustervar,Buffer,b);

59

          for (int a = 0;a<512;a++)

60

            {

61

            printf ("%c",Buffer[a]);

62

            }

63

        }

64

      }

65

}

Als ich ein Fat16 Dateisystem entwickelte trat folgender Fehler auf:
laut FAT16 Spec(PCIntern 3.0) darf der letzte Sektor einer Datei in der 
FAT
mit dem Wert FFF7..FFFF gekennzeichnet sein. Es war festzustellen daß 
bei Verwendung der Werte FFF7..FFFF zumindest bei "Notepad" nur eine 
leere Datei angezeigt wurde. Der Doseditor "Edit" hatte dieses Problem 
nicht. Testsystem
Win2000 Stand 2003.
Schau dir doch mal mit dem Hexeditor an, wie die Datei in der FAT 
abgeschlossen ist.

@Wolfram: Ist ein Sektor 512 Byte groß? Wenn ich nun 512 Byte in meine 
Datei geschrieben habe, muss ich am Ende des ersten Sektors gucken oder?
Im ersten Sektor steht folgendes:
EB 3C 90 4D 53 44 4F 53 35 2E 30 00 02 04 08 00
02 00 02 00 00 F8 F4 00 3F 00 FF 00 20 00 00 00
E0 D1 03 00 00 00 29 E7 89 A1 60 4E 4F 20 4E 41
4D 45 20 20 20 20 46 41 54 31 36 20 20 20 33 C9
8E D1 BC F0 7B 8E D9 B8 00 20 8E C0 FC BD 00 7C
38 4E 24 7D 24 8B C1 99 E8 3C 01 72 1C 83 EB 3A
66 A1 1C 7C 26 66 3B 07 26 8A 57 FC 75 06 80 CA
02 88 56 02 80 C3 10 73 EB 33 C9 8A 46 10 98 F7
66 16 03 46 1C 13 56 1E 03 46 0E 13 D1 8B 76 11
60 89 46 FC 89 56 FE B8 20 00 F7 E6 8B 5E 0B 03
C3 48 F7 F3 01 46 FC 11 4E FE 61 BF 00 00 E8 E6
00 72 39 26 38 2D 74 17 60 B1 0B BE A1 7D F3 A6
61 74 32 4E 74 09 83 C7 20 3B FB 72 E6 EB DC A0
FB 7D B4 7D 8B F0 AC 98 40 74 0C 48 74 13 B4 0E
BB 07 00 CD 10 EB EF A0 FD 7D EB E6 A0 FC 7D EB
E1 CD 16 CD 19 26 8B 55 1A 52 B0 01 BB 00 00 E8
3B 00 72 E8 5B 8A 56 24 BE 0B 7C 8B FC C7 46 F0
3D 7D C7 46 F4 29 7D 8C D9 89 4E F2 89 4E F6 C6
06 96 7D CB EA 03 00 00 20 0F B6 C8 66 8B 46 F8
66 03 46 1C 66 8B D0 66 C1 EA 10 EB 5E 0F B6 C8
4A 4A 8A 46 0D 32 E4 F7 E2 03 46 FC 13 56 FE EB
4A 52 50 06 53 6A 01 6A 10 91 8B 46 18 96 92 33
D2 F7 F6 91 F7 F6 42 87 CA F7 76 1A 8A F2 8A E8
C0 CC 02 0A CC B8 01 02 80 7E 02 0E 75 04 B4 42
8B F4 8A 56 24 CD 13 61 61 72 0B 40 75 01 42 03
5E 0B 49 75 06 F8 C3 41 BB 00 00 60 66 6A 00 EB
B0 4E 54 4C 44 52 20 20 20 20 20 20 0D 0A 44 61
74 65 6E 74 72 84 67 65 72 20 65 6E 74 66 65 72
6E 65 6E FF 0D 0A 4D 65 64 69 65 6E 66 65 68 6C
65 72 FF 0D 0A 4E 65 75 73 74 61 72 74 3A 20 54
61 73 74 65 20 64 72 81 63 6B 65 6E 0D 0A 00 00
00 00 00 00 00 00 00 00 00 00 00 AC C4 D3 55 AA

Kannst du damit was anfangen? Ich nämlich nicht viel :)

Editieren ging ja hier nicht oder?

Habe mich nämlich gerade vertan. Ich hatte sie eben nicht mit dem 
Controller sondern mit Windows beschrieben und so sieht meine Datei auf 
der SD Karte aus, wenn ich sie mit Windows beschrieben habe.
Mein Atmega kann diese Datei auch so richtig auslesen, ich kann halt nur 
nichts reinschreiben, was ein Rechner dann auslesen kann.

Gruß,

Marian

>Ist ein Sektor 512 Byte groß? Wenn ich nun 512 Byte in meine
>Datei geschrieben habe, muss ich am Ende des ersten Sektors gucken oder?
>Im ersten Sektor steht folgendes: ...Hex
>Kannst du damit was anfangen?
ja
>Ich nämlich nicht viel
und das ist das Problem

1. ein Sektor ist 512 Byte groß
2. nein
zu dem Hex, was du da geschickt hast ist der Bootsektor des FAT16 zu 
erkennen an EB 3c 90 das ist ein jmp zum Bootprogramm und dem 
abschließenden 55 AA.
Dekodiere ihn und suche dir die Adresse des Hauptverzeichnisses , suche 
dort den Dateieintrag (ich gehe mal davon aus das sie im 
Hauptverzeichnis liegt) dort suchst du dir die Clusternummer raus. Diese 
Clusternummer suchst du in der 1. FAT und folgst der Clusterkette bis 
ans Ende. Überprüfe wie lang die Clusterkette ist und womit sie 
abgeschlossen ist.
Einführende Literatur:
PCIntern 3.0 ,Tinschert

Ein paar Fragen, um zu wissen ob ich etwas richtig verstanden habe:

Das Programm was ich von Ullrich Radig habe, sucht doch schon auf der SD 
Karte nach der Datei und deren Clusternummer sowie Adresse usw. Genau 
das soll ich doch jetzt mit dem Hexeditor machen oder? Aber wozu soll 
ich das machen, wenn das eigentlich vom Programm erledigt wird? Die 
Clusternummer zeigt mir doch an, wo die Datei startet und mit den Blocks 
kann ich dann immer 512 Byte dort hinein schreiben.

Ich meine, das Programm schreibt doch nur etwas in die Datei, wenn diese 
auch gefunden wurde. Liege ich falsch, wenn ich denke, dass dann auch in 
die gefundene Datei geschrieben wird?

Entschuldigt, falls die fragen verwirrend sind aber das Thema ist recht 
neu für mich und ich steige da noch nicht richtig durch.

>Ein paar Fragen, um zu wissen ob ich etwas richtig verstanden habe:
du hast das genau richtig verstanden.
Tatsache ist, irgendetwas läuft schief, deshalb kommt es zu 
"Lesefehlern"
bei Win und Linux. Das heißt du mußt überprüfen was schief läuft.
Da die Problematik neu für dich ist, bist du höchstwahrscheinlich nicht 
in der Lage Fehler zu erkennen ohne dich in die FAT16 Strukturen 
einzulesen.

Ich kenne den Code von Uli Radig nicht. Entweder ist dort ein Fehler 
(eher unwahrscheinlich) oder du verwendest ihn falsch. Die meisten FAT16 
Implementierungen aus dem Hobbybereich die ich kenne können Dateien 
nicht vergrößern oder neu anlegen. Ich weiß nicht ob dies für Uli Radig 
Implementierung zutrifft.

Ich habe endlich das Problem verifiziert.

Das Auslesen unter Windows funktioniert nur, wenn man beim Erstellen der 
Datei auch etwas hineinschreibt. Lässt man diese leer und versucht sie 
mit dem Controller zu beschreiben passiert nichts. Schreibt man 
allerdings etwas hinein, kann Windows auch das lesen, was der Controller 
zuvor hineingeschrieben hat.

Ich weiß nicht ob das an meiner Unwissenheit lag aber ich finde, dass 
man das ruhig hätte erwähnen können :).

Mal schauen wie lange das nächste Problem auf sich warten lässt.

Gruß,

Marian

Hm hört sich interessant an und sieht auch so aus, nur leider habe ich 
gerade nicht die Zeit da auch noch reinzugucken.

Ich komme ja mit dem Code von Uli ziemlich gut klar mittlerweile aber 
ein Problem habe ich immer noch bzw. ich weiß nicht warum das so ist.

Ich schrieb ja folgendes:
"Schreibt man
allerdings etwas hinein, kann Windows auch das lesen, was der Controller
zuvor hineingeschrieben hat."

Das stimmt leider nicht ganz. Je nach dem wieviel man mit Windows in die 
Datei hineinschreibt, so viel kann auch nur der Controller 
hineinschreiben(zumindest so, dass es Windows lesen kann), also wenn man 
10 Zeichen in die Datei schreibt, kann Windows auch nur 10 Zeichen aus 
der durch den Controller beschriebenen SD Karte lesen. Ich finde das 
ziemlich seltsam, kann mir das vielleicht jemand erklären?

Mir fällt gerade noch etwas ein. Kann man mit dem Code von Uli immer nur 
512 Byte schreiben, also muss ich mein Array immer mit 0 auffüllen. wenn 
es nicht 512 Byte enthält?

PS: Ich hoffe, dass ließt mal jemand der sich mit dem Code von Uli 
auskennt :)

Gruß,

Marian

>PS: Ich hoffe, dass ließt mal jemand der sich mit dem Code von Uli
>auskennt :)

Also wenn das Uli's SourceCode2_5 ist solltest du wirklich
auf was anderes umsteigen. elm wurde oben ja schon erwähnt.
Habe ich auch schon ausprobiert. Klappt gut. Kann auch FAT32
und SDHC Karten.

Das ist von mir:
http://www.holger-klabunde.de/avr/avrboard.htm#FullFAT

Sehr einfach zu bedienen ! Hält sich einigermaßen an die
Befehlsnamen die man vom PC her kennt. elm kann zwar mehr,
dafür bin ich schneller ;) Liest und schreibt FAT12,16,32.
SDHC geht auch.

Dann gibts in der Codesammlung noch Roland Riegel (nur FAT16 ?).
Hab ich einen vergessen ?


Bei elm und meinem FAT kannst du selber Dateien mit dem
uC erzeugen. Die müssen nicht vorher mit Windows draufgespielt
werden. Und du kannst gnadenlos in die Datei reinschreiben so
viel du möchtest. Bis die Karte voll ist. Das geht bei einem
Byte los, bis zu soviel Speicher wie du entbehren kannst.

Gruß
 Holger

Der Sektorpuffer ist in den 0.7kB mit drin.
Der FAT Buffer geht extra !

Achso FAT-Buffer ?
Dort wird ein kompletter Sektor der FAT im Speicher
gehalten. Das bringt einige Karten beim schreiben
ordentlich auf Tempo.

@holger: Deine Routinen höhren sich auch gut an :). Ich werde diese 
gleich mal testen. Ich habe noch eine Frage zu diesem hier :
//###################################################################
// unsigned char Fopen(char *name, unsigned char flag)
//###################################################################

Funktion:  Öffnet eine Datei zum lesen ODER schreiben

Parameter: "name" ist der DOS 8.3 Name der zu öffnenden Datei
           "flag" F_READ Datei zum lesen öffnen
           "flag" F_WRITE Datei zum schreiben öffnen

Rückgabe:  F_OK wenn die Datei geöffnet werden konnte.
           F_ERROR wenn die Datei nicht geöffnet werden konnte
           oder bereits eine Datei offen ist.

           Wenn F_WRITE benutzt wird und die Datei noch nicht
           existiert, wird versucht eine neue Datei anzulegen.
           Wenn die Datei bereits existiert wird an ihr ENDE
           vorgespult um Daten anzuhängen. Es ist nicht vorgesehen
           alte Daten zu überschreiben.

           Das aktuelle Verzeichnis wird automatisch vergrößert wenn
           keine Einträge mehr frei sind. Das geht bei FAT12 und FAT16
           nicht wenn man sich im RootVerzeichnis befindet. Die Anzahl
           der Einträge ist fest vom Dateisystem vorgegeben.

           Wer mehr als 512 Dateien anlegen will MUSS bei FAT12 und
           FAT16 in einem Unterverzeichnis arbeiten !

Habe ich es richtig verstanden, dass man unbedingt ein Unterverzeichniss 
braucht, um Dateien automatisch vergrößern zu lassen? Also wenn ich im 
Rootdirectory eine Datei habe, dann kann ich diese nicht mit deinen 
Routinen benutzen,wenn sie größer werden soll?

Gruß,

Marian

> Habe ich es richtig verstanden, dass man unbedingt ein Unterverzeichniss
> braucht, um Dateien automatisch vergrößern zu lassen?

Nein!
Es geht hier um die ANZAHL DER MÖGLICHEN EINTRÄGE (Files) im 
Rootverzeichnis.
Die ist bei FAT16 theoretisch 512.
In der Praxis aber nur 255, weil unter Windows zusätzlich Platz für die 
langen Dateinamen vergeudet wird.
Versuch mal unter Windows mehr als 255 Dateien ins Rootverzeichnis 
Deiner Flashkarte zu kopieren :-)

Wenn Du eine Datei überschreiben willst, musst Du den Dateizeiger auf 
den Anfang setzen können (geht normalerweise mit "Seek"). Musste gucken, 
ob Dein Projekt Seek hat. Bei Roland Riegel gehts.

Eines aber ist klar:
Du wirst Dich wohl oder übel mit der Theorie der FAT-Filesysteme 
auseinandersetzen müssen. Es gibt tonnenweise Infos im Web.
Anhand Deiner Fragen ist ersichtlich, dass Du wenig Ahnung hast.
Dein Projekt wird sonst scheitern, sobald irgendeine Kleinigkeit nicht 
passt.

Joachim

Ja, ich weiß selbst das ich nicht genug Ahnung habe aber daran kann ich 
jetzt so schnell nichts ändern, da dieses Gebiet auch sehr umfangreich 
ist.

Ich habe überall im Netz nur gelesen, wie einfach es ist SD Karten mit 
µCs zu verwenden. Das Lesen einer ist ja auch recht simple nur das 
beschreiben bereitet mir Kopf zerbrechen, da ich momentan nur noch ca. 
1KB Ram übrig habe. Da kam mir der Code von Uli recht passend, da er 
sehr klein war :). Leider wusste ich vorher nicht, dass das beschreiben 
mit diesem Code nicht ganz so einfach ist.

Ich habe nun den von elmchan (http://elm-chan.org/fsw/ff/00index_e.html) 
ausprobiert aber der benötigt viel zu viel Speicher.

Jetzt werde ich mich noch an Holgers Code 
(http://www.holger-klabunde.de/avr/avrboard.htm#FullFAT) versuchen aber 
da weißt ich noch nicht so ganz, was ich alles benötige wenn ich "nur" 
schreiben und lesen möchte, da in seinem FATSingle-Ordner doch sehr viel 
Dateien sind.
Mal schauen ob ich das geordnet bekomme.

Gruß,

Marian

Ich bins mal wieder :),

ich habe nun den Code von Holger zum laufen gebracht aber es gibt einige 
Probleme. Es hapert in der GetDriveInformation() Routine.
Die Routine arbeitet leider nur bis zum Punkt, wo der FAT Typ bestimmt 
werden soll, also bis hier :

1

 loop=0;

2

   do

3

    {

4

     // Jetzt checke ich doch den FAT-String im Bootsektor um den Typ der FAT

5

     // zu bestimmen. Einen besseren Weg sehe ich im Moment nicht.

6

     if(   boot->eb.rm.BS_FilSysType[0]=='F'

7

        && boot->eb.rm.BS_FilSysType[1]=='A'

8

        && boot->eb.rm.BS_FilSysType[2]=='T'

9

        && boot->eb.rm.BS_FilSysType[3]=='1'  )

10

       //Wenn ich hier ankomme habe ich entweder FAT12 oder FAT16

11

#ifdef USE_FAT12

12

       if(boot->eb.rm.BS_FilSysType[4]=='2') FATtype=FAT12;

13

#endif

14

#ifdef USE_FAT16

15

       if(boot->eb.rm.BS_FilSysType[4]=='6') FATtype=FAT16;

16

#endif

17

      }

18

     else

19

      {

20

#ifdef USE_FAT32

21

       if(   boot->eb.rm32.BS_FilSysType[0]=='F'

22

          && boot->eb.rm32.BS_FilSysType[1]=='A'

23

          && boot->eb.rm32.BS_FilSysType[2]=='T'

24

          && boot->eb.rm32.BS_FilSysType[3]=='3'

25

          && boot->eb.rm32.BS_FilSysType[4]=='2'  )

26

        {

27

         FATtype=FAT32;

28

        }

29

       else //war kein Bootsektor, also feststellen wo der liegt

30

#endif

31

        {

32

         mbr=(struct MBR *)iob; //Pointer auf die Partitionstabelle

33

         bootSecOffset=mbr->part1.bootoffset; //Nur den brauche ich

34

   by=ReadSector(bootSecOffset,iob);      //read bootsector

35

         boot=(struct BootSec *)iob;

36

        } 

37

      }

38

39

     loop++;

40

    }while(loop<2 && FATtype==0); //Bis zu zwei Versuche den Bootsektor zu lesen

Vorher kann ich folgendes auslesen : c_size,c_size_mult,DriveSize und 
maxsect. Die Werte stimmen leider nicht ganz, z.B. ist Drivesize nur 
98816KB groß, obwohl ich eine 128MB Karte verwende. Jedenfalls wird in 
der oben genannten Routine keine FAT-Art erkannt und wenn er danach den 
bootsector lesen möchte ist ganz schluss, da bootSecOffset den Wert 
4294967295 hat und somit bricht er dann natürlich in der 
ReadSector-Routine ab. Leider bin ich jetzt bei der Fehlersuche hängen 
geblieben. Ich habe versucht, alles einzustellen was geht(also alle 
defines usw.) aber es ändert sich nichts an meinem Problem.

Hat jemand eine Idee woran das liegen kann?

Gruß,

Marian

Formatiere die Karte mal.

Hab ich schon getan. Habe aber nur Windows zur Verfügung. Reicht das?

Nehm ich nur ;)

Hm, woran liegt es dann? Keine der beiden if-Abfragen auf den FAT1. oder 
FAT32 trifft zu. Ich verstehe das nicht. Mit der falsch ausgelesenen 
Kartengröße hat das nichts zu tun?

Ich habe es gerade mit der FAT32 formatierung probiert und es ist exakt 
das gleiche Ergebnis.

Hast du noch einen Ratschlag :) ?

>Drivesize nur 98816KB groß

Was zeigt Win denn für Speicherplatz an ?

Das der FAT Typ nicht erkannt wird könnte
daran liegen das deine Schaltung 8MHz SPI Tempo
nicht mag. Wie sieht die aus ?

Windows zeigt 127918 KB an.
Das SPI Tempo habe ich runtergeschraubt auf 57,6 kHz also SPR1 und SPR0 
auf 1 gesetzte bei einem µC-Takt von 7,3728MHz.

@Rufus: Damit kenne ich mich leider nicht so gut aus...was meinst du 
damit?

Den Schaltplan darf ich leider nicht online stellen, deshalb schreibe 
ich es euch:

-Atmega32-L mit 7.3728MHz, d.h. SPI Takt von 57,6 KHz
-Versorgung: LiPo-Akku 3.6 V , 1200mAh

Ich verwende keine Spannungsteiler an den SPI Leitungen, da mein ganzes 
System durch 3.3V Spanungsregler begrenzt wird, d.h. die Pins der SD 
Karte sind direkt mit dem Atmega32 verbunden. Ich habe auch noch einen 
Sensor in der Schaltung, den ich Problemlos über SPI auslese.

Also das Problem hat sich seit heute Morgen irgendwie von alleine gelöst 
bzw. ich weiß nicht warum es jetzt funktioniert.

@Rufus: Das soetwas geht wusste ich auch noch nicht. Ich habe aber das 
JTAG Interface eh deaktiviert.

@Philipp: Nein der Atmega läuft nicht mit 3.3 V sondern hängt direkt am 
Akku.

Jedenfalls kann ich jetzt die Karte richtig auslesen und auch 
beschreiben und lesen.

Auch hier noch einmal ein Dank an alle die mir geholfen haben.

Gruß,

Marian