SD-Card an MSP430F1612 (wieder mal.)

Hallo...und Deine Files hast Du nicht mehr??? Ahhhhh, schade!!!
Klar kann man in den Header-Files ne Menge einstellen, aber ich will mir 
ersparen, alles *per Hand durchzugehen...

Wie hast Du das dann ohne nen FAT gemacht?
Danke

Hallo Mathias,

schön, ich mache gerade was ähnliches, siehe auch meinen Beitrag von 
heute. Die Beschaltung und Software läuft schon teilweise. Ich kann auf 
die Karte schreiben, aber nicht lesen. Ich bin jetzt im Büro, kann Dir 
aber heute abend Links geben. Dort findest Du Informationen zu FAT16, 
langen Dateinamen etc.

Zu Deiner Frage mit der TI-Doku: Ja, ich habe SOMI und SIMO vertauscht, 
weil der MSP als Master läuft. Das geht auch aus der Doku zu SPI von TI 
hervor, also nicht aus dem Dok slaa281a.pdf.

Gruß
Uli

Hallo Uli, wäre super mit den Links...
irgendwie muss die Sache doch zum laufen zu kriegen sein...

Wohin hast du den Pin1 von der SD-Card gelegt? Auf Px.0 (wie ich) oder 
Px.4 (wie im appnote)? Das ist so eine Sache, die mir irgendwie nicht 
ganz einleuchtet...
@Uli: hast du ein schematic da?

@ reflection: wenn Du die files noch finden würdest, wäre super.
Aber dann schrieb auch mal bitte, WIE Du die SD-Card an den MSP 
drangebastelt hast...mit nem schematic als pdf oder so...

Wenn gewünscht, kann ich mein schematic auch mal dranhängen...

Gruß
Mathias

Hallo Mathias,

ich habe !CS an P5.4, wie in der Appnote. Scheint auch zu funktionieren. 
Ich kann ja bloss nichts von der Karte lesen. Also muß die restliche 
Belegung wohl stimmen, sonst könnte ich nichts schreiben. Oder? Ich bin 
mir nicht 100% sicher...

Guck' mal unter

http://home.teleport.com/~brainy/fat16.htm und
http://home.teleport.com/~brainy/lfn.htm

Auch lesenswert ist der FAT16-Artikel auf wikipedia.
Ich habe aber auch vermutlich geringere Ansprüche an das FAT als Du. Ich 
will lediglich aus dem Root-Verzeichnis lesen und auch nur dort 
schreiben. Ich glaube, dass das die Sache sehr vereinfacht.

Ich kriege nix gelesen. Ist doch zum K****n!

Im Anhang ist ein Ausschnitt von mir. Da ist kein µC zu sehen. Ich habe 
stattdessen Steckerleisten eingezeichnet. Die sind aber Pinkompatibel...

Gruß
Uli

Hallo, hast es ja wirklich genauso gemacht, wie im appnote...
Danke für die Links...da hab ich ja was zu Lesen heute Abend ;-)

Ich habe mal meines angehängt.
Ich habe es hier her:
http://www.cs.ucr.edu/~amitra/sdcard/Additional/sdcard_appnote_foust.pdf
(von Seite 3)

Aber ich habe gerade festgestellt, dass die mit !SS den Px.4 meinen und 
nicht Px.0. In deren Software ist es P3.4.
ICH habe den aber an P5.0 dran...weil ich es wie geschrieben aus der 
ganz oben genannten Quelle habe.
hxxp://www.olimex.com/dev/images/MSP430-4619LCD-sch.gif

Also werde ich wohl nen neuen Adapter basteln, der dann auch mit der 
Appnote übereinstimmt, sonst müsste ich ja soviele Sachen dran ändern...

Könnte es bei deinem Lese-Problem an den fehlenden PullUP-Widerständen 
liegen? Kannst ja mal testen...

Wie heißt denn die Appnote für das SPI? Habs auf die schnelle nicht 
gefunden.

Mathias

Ich meinte mit SPI-Doku keine spezielle Appnote, sondern einfach das 
Kapitel "14.2 USART Operation: SPI Mode" aus dem 'normalen' MSP430x1xx 
User Guide.

Die Pullup-Widerstände. Ja, das ist richtig. Die sind aber doch 
eigentlich nur wichtig, wenn keine SD-Karte steckt, damit die Eingänge 
vom MSP definiert sind. Jedenfalls denke ich das. Deswegen habe ich sie 
meinem ersten Entwurf einfach mal weggelassen (ist eh nur ein 
Experimentieraufbau)... Meinst Du trotzdem, dass es daran liegen könnte? 
Das werde ich dann heute noch mal ausprobieren.

...Ich weiß es nicht, bin was MSP430 angeht absoluter noob.

Aber Versuch macht kluch, oder?
Schaden können die PullUP's jedenfalls nicht...

Mathias

So, habe mal angefangen mich durch den Code von der Appnote slaa281a zu 
hangeln.
Schon tauchen die ersten Merkwürdigkeiten auf.

Ich habe mal die komplette *.zip angehängt.

mmc.c :

Die Funktion initMMC

1

char initMMC (void)

2

{

3

  //raise SS and MOSI for 80 clock cycles

4

  //SendByte(0xff) 10 times with SS high

5

  //RAISE SS

6

  int i;

7

  // Port 5 Function           Dir       On/Off

8

  //         5.0-mmcCD         Out       0 - card inserted

9

  //         5.1-Dout          Out       0 - off    1 - On -> init in SPI_Init

10

  //         5.2-Din           Inp       0 - off    1 - On -> init in SPI_Init

11

  //         5.3-Clk           Out       -                 -> init in SPI_Init

12

  //         5.4-mmcCS         Out       0 - Active 1 - none Active

13

  P5SEL |= 0x0E;

14

  P5SEL &= ~0x11;

15

  P5OUT |= 0x10;

16

  P5DIR |= 0x1A;

17

18

  initSPI();

19

  //initialization sequence on PowerUp

20

  CS_HIGH();

21

  for(i=0;i<=9;i++)

22

    spiSendByte(0xff);

23

24

  return (mmc_GoIdle());

25

}

1) Muss es nicht im Kommetar heissen, dass P5.0 ein INPUT ist, denn in 
der Funktion mmc_ping (mmc.c) wird das erste Bit des Ports 5 
abgefragt...also INPUT???
Ausserdem Wird ja per P5DIR |= 0x1A; bit0 als Eingang definiert.

2) P5SEL |= 0x0E; (0000 1110) bedeutet, dass für die Pins P5.1 bis P5.3 
die Zweitfunktion gelten soll, richtig???

3) Was soll dann P5SEL &= ~0x11; ?? das macht doch nochmal genau das 
gleiche, oder?

Erst steht in P5SEL 0000 0000 drin.
Dann P5SEL |= 0x0E; damit steht jetzt 0000 1110 drin
Dann P5SEL &= ~0x11; also wird 0000 1110 mit 1110 1110 "geUNDet", was 
wieder 0000 1110 bedeutet...???

4) Die Funktion mmc_ping():

1

char mmc_ping(void)

2

{

3

  if (!(P5IN & 0x01))

4

    return (MMC_SUCCESS);

5

  else

6

    return (MMC_INIT_ERROR);

7

}

Kann mir mal bitte einer erklären, was if (!(P5IN & 0x01)) bedeutet.
Diese Kurzschreibweisen in den TI_codes sind für Anfänger echt ein 
Graus!
Meine Erklärung:
Wenn die Abfrage des Port5 Pin0 false ist, dann gib MMC_SUCCESS zurück.
Man könnte es auch so schreiben if ((P5IN & 0x01) == 0)...  , oder?


danke

mathias

if (!(P5IN & 0x01))

Pin 5 wird mit 0x01 verundet. Raus kommt == 0 oder != 0. Der folgende 
Code wird also nur ausgeführt, wenn das erste Bit von PIN5 NICHT gesetzt 
ist, da das ! ja verneint.

Gruß
Uli

Und noch was: Wenn Du den Code von TI am laufen hast, pass genau auf, 
wann char und unsigned char verglichen wird. Das ist knifflig. Bei mir 
hat das mit dem Lesen genau aus diesem Grund nicht funktioniert, bis ich 
die Compiler-Option "plain_char=unsigned" gesetzt habe...

OK, danke...für welche Pins wird denn nun die Zweitfunktion verwendet?

P5SEL ist doch standartmäßig 0000 0000, also Erstfunktion, oder?
Es wird auch vorher im Code nicht verändert.
Was wieder 3) auf den Plan ruft...

Wenn es wirklich 1111 1111 WÄRE, dann würde nach der ganzen Aktion ja in 
P5SEL 1110 1110 drin stehen.
Also alle bis auf P5.0 und P5.4 wäre auf Zweitfunktion gestellt.
Was ja ziemlich dämlich ist, weil P5.5 bis P5.7 im Code NIEMALS 
vorkommen.

Gruß
mathias

Nö, würde ich nicht sagen. 0x11 bezieht sich nämlich nicht auf das 
gesamte restliche Byte 0xF1 schon!

0x11 =    10001
0xF1 = 11110001

0x11 läßt also alles was nicht verstellt werden soll in Ruhe...

@Stefan Achso, dann sorry. Das war sowieso etwas oberlehrerhaft bzw. 
einfach Klugscheißerei von mir... ;-)

@Mathias Da wir jetzt ja noch was ähnliches vorhaben, SD zum Laufen 
bringen und dann FAT16, wäre ich sehr an einem Erfahrungsaustausch 
interessiert. Der Krempel ist ja für uns beide Neuland. Was meinst Du? 
Ich komme wahrscheinlich erst wieder ab Freitag dazu, aber wenn ich 
irgendwas zum Laufen bringe, werde ich Dich das einfach mal wissen 
lassen. Umgekehrt wäre ich Dir auch dankbar für Neuigkeiten... :-)

Hallo Uli, da ich dies im Zuge meines Diploms brauche, werde ich wohl 
fast täglich dransitzen... ;-)
Erfahrungsaustausch ist super! Bin dabei...

Hallo, ich habe gestern mal meine kleine Platine verändert,
damit die Belegung jetzt wie im TI_Sample ist.

Hier meine jetzige Anbindung:

SD-Card                       MSP430F1612
-----------------------------------------
Pin 1 Dat3/CS/CD              P5.4/ MCLK
Pin 2 Data IN                 P5.1/ SIMO1
Pin 3 GND
Pin 4 Vdd
Pin 5 CLK                     P5.3/ UCLK1
Pin 6 CD                      P5.1/ STE1
Pin 7 Data OUT                P5.2/ SOMI1
Pin 8 per PullUp auf 3.3V
Pin 9 per PullUp auf 3.3V

Jetzt habe ich mal das Programm von T druchlaufen lassen.
Siehe Beitrag vom Datum: 17.09.2007 21:56 von mir...

Die Initialisierung scheint zu funktionieren, denn:

Er gibt mir im Debugger eine CardSize von 507379712 aus. Nun gut...
Die SD-Card (Sandisk 512MB) ist laut Windows-Datei-Explorer mit FAT16 
formatiert
und hat 507.052.032 Bytes freien Speicher. Das entspricht rund 483MB.

Der Hex-Editor WinHex gibt mir ebenfalls die 507.052.032 aus.
Allerdings soll die gesamte Kapazität bei 507.201.024 Bytes liegen.
Das weicht ein wenig von der vom Programm ausgegebenen Größe ab, soll 
mich aber jetzt nicht weiter stören.

1

unsigned char buffer[512];

2

3

int main( void )

4

{

5

  WDTCTL = WDTPW + WDTHOLD;

6

7

  initMMC();

8

9

  while ((mmc_ping() != MMC_SUCCESS));      // Wait till card is inserted

10

11

  // Read the Card Size from the CSD Register

12

  cardSize =  MMC_ReadCardSize();

13

14

  for (i = 0; i <= 512; i++) buffer[i] = i;

15

  mmcWriteSector(1, buffer);                // write a 512 Byte big block beginning at the (aligned) adress

16

17

  for (i = 0; i <= 512; i++) buffer[i] = i+64;

18

  mmcWriteSector(2, buffer);                // write a 512 Byte big block beginning at the (aligned) adress

19

20

  mmcReadSector(1, buffer);                 // read a size Byte big block beginning at the address.

21

22

  mmcReadSector(2, buffer);                 // read a size Byte big block beginning at the address.

23

24

  mmc_GoIdle();                             // set MMC in Idle mode

25

26

  while (1);

27

}

Er schreibt ein Array aus 512bytes. Dieses ist mit 0, 1, 2, ..., 511 
belegt.
Dieses Array wird jetzt in Sektor 1 der SD-Card geschrieben.
Danach überschreibt er das Array (buffer[i]) mit neuen Werten 64, 65, 
..., 566.
Dieses Array wird jetzt in Sektor 2 der SD-Card geschrieben.

Danach liest er die Sachen wieder aus, wobei ich noch nicht weiss, wie 
ich überprüfen kann, ob er es tatsächlich macht...

Was ich jetzt nicht begreife, ist:

Müsste ich nicht im WinHex sehen, dass im Sektor 1 und im Sektor 2 Daten 
drin stehen?
Der erste Sektor beginnt wohl bei 512 und endet bei 1023.
Im Bild sieht man, dass bei
512 F8, bei 513 FF, bei 514 FF und bei 515 FF drin steht, danach wieder 
Nullen.
Das sollen doch die einzelnen Bytes sien, oder? aber warum ZWEI stellen? 
Nen Byte sind doch ACHT bit.

Wo oder wie kann ich mir die "Daten" anschauen, die auf die SD_Card 
geschrieben wurden.

Sorry, für die evtl. blöden Fragen, aber ich kenn mich mit der MAterie 
noch nicht ganz so gut aus...habt Verständnis ;-)

mathias

Vielleicht solltest du dir folgende Zeile nochmal gaaaanz genau 
angucken:

1

for (i = 0; i <= 512; i++) buffer[i] = i;

Das macht mir hoher Wahrscheinlichkeit nicht das, was du möchtest.

Ebenso das 2. Füllen des Buffers.

Hast du den Buffer nach dem Füllen mal im Debugger angeschaut?

?? Also der Code kommt ja nicht von mir, sondern von TI.

Ich hab die for() - Schleife mal im debugger "beobachtet". Und da 
schreibt er in buffer[0] ne 0, in buffer[1] ne 1 usw.
und dann in der zweiten for() halt in buffer[0] ne 64 usw....

>>Hast du den Buffer nach dem Füllen mal im Debugger angeschaut?

Wie meinst Du das?

Mathias

OK, das mit den 513bytes leuchtet ein, aber wie gesagt, die Sache ist 
nicht auf meinem Mist gewachsen...

Das mit den zwei Stellen habe ich eben auch herraus gefunden... ;-) auch 
logisch!

Aber wo sehe ich denn jetzt die Daten im Hex-Editor?

Ich habe mal auf die Karte eine Test.txt gemacht.
Im HexEditor hat er dann bei der logischen SektorNr. 243 (physical 
SectorNr 480) nen Eintrag mit dem Dateinamen...

Und ab logischer SektorNr. 275 (pysical 512) steht der in der datei 
enthaltenen text drin...also DAS kann ich mir schonmal anschauen, aber 
wo sind die Daten vom MSP???

mathias

Hallo, hmmm, na mal schauen.

Also die Funktion mmcWriteSector ist folgendermaßen definiert.

#define mmcWriteSector(sector, pBuffer) mmcWriteBlock(sector*512ul, 512, 
pBuffer)

Was bedeutet denn eigentlich sector*512u1?
Das *512u1 irritiert mich etwas? Was ist denn 512u1?

Ich meine, wenn sector 1 ist, wäre das ja die Stelle, an der der 
reingeschriebene Buffer beginnt...

mathias

...also müsste er, bei

1

mmcWriteSector(1, buffer);

die daten an die physikalische sektor no. 1*512 schreiben?
Und dieses "ul" ist ein Typecast? Nur in anderer Schreibweise?
danke

Nee, das ist für den Präprozessor, damit der weiß, dass die Variable 
eine Länge von unsigned long haben kann, und entsprechend Speicherplatz 
reserviert.

Irgendwie ziemlich unclever, solch lange Variablen als 
Übergabeparameter....das wird alles durch die Arbeitsregister 
geschleift....hmm...naja, der Code ist ja nicht direkt von TI, den haben 
die dann mal irgendwann reingenommen, den gabs vorher schon im Netz von 
Privat....

Hallo Stefan,

da hast Du sicher Recht, ABER die SD_Card_Geschichte macht ungefähr nur 
1% der ganzen Arbeit aus.
Ich hätte gerne die Zeit, ALLES bis ins letzte Detail zu verstehen, aber 
irgendwann MUSS ich ja auch abgeben...
Ich möchte auch nicht einfach nur C&P anwenden; lernen möchte ich dabei 
schonwas...

mathias

@uli:

ich hab dir mal ne mail geschrieben...nur falls sie in deinem 
spam-ordner gelandet sein sollte...

Hallo, also die Schreibgeschichte läßt mich irgendwie nicht los...
es geht irgendwie nicht...

Ich habe mal einen Screenshot angehängt, bei dem mir etwas komisch 
vorkommt...

Zu sehen ist der logisch 0te Sektor meiner SD-Card. Warum die 
Nummerierung der physikalischen SektorNr. bei 237 weiß ich nicht. Weiß 
einer warum?

Das ist also sicher der MBR und die FAT-Einträge ganz am Anfang der 
Karte.

Was ich jetzt komisch finde, ist dass in der ASCII-Ansicht rechts steht:
"...Datentr„ger entfernenÿ Medienfehlerÿ Neustart: Taste drcken"

Was ist denn das für ein "Medienfehler".
Könnte das damit zu tun haben, dass mein MSP zwar was auf die Karte 
schreibt, und auch liest, denn die Variablen für erfolgreiches Schreiben 
und Lesen werden ja gesetzt, aber ich trotzdem die Daten nicht sehen 
kann?

Kann mir das einer erklären?

Ich verwende den Code von TI. (wurde etwas weiter oben schon gepostet)
Habe bis auf den hardwareseitigen Tausch von SOMI und SIMO, sowie die 
Änderung der Initialisierung:
statt:

1

for (i = 0; i <= 512; i++) buffer[i] = i;

habe ich

1

for (i = 0; i < 512; i++) buffer[i] = i;

gemacht, weil der Buffer ja nur 512 und nicht 513 Elemente aufnehmen 
kann.

Ich habe auch mal einen zweiten Buffer erstellt.
Es wird dann der Buffer von TI von der Karte gelesen und in meinen 
eigenen geschrieben. Macht er alles, so wie er soll...aber ich finde 
halt die Daten auf der Karte nicht...

Hat einer eine Idee?
danke

mathias

*edit: komisch finde ich ja auch, dass der "used space" bei null ist.
Wird also wirklich nichts vom MSP draufgeschrieben?

Ich nehme an, die Pin-Belegung ist die Gleiche? Dann wirds wohl keine 
Probleme geben.

http://www.priio.com/FlashFile.pdf

seite 6...

Ah, danke !

Genau so etwas habe ich gesucht.