Hallo!
Ich habe mir eigene Routinen in Assembler geschrieben, um die SD-Karte
zu initialisieren. Beim Senden des CMD0 funktioniert das auch, ich
bekomme eine 1 zurück, allerdings bekomme ich die auch bei einem CMD1
immer zurück, ich habe es schon in einer Schleife versucht, die über
eine halbe Minute lang CMD1 sendet und immer nur 1 empfängt.
meine Routine:
!ANMERKUNG! in r1 steht immer eine 0 und in r2 immer 255
.equ SD_Addr = 0x60 ;reservierter SRAM Speicher für SD-Karten Befehl
SD_SendCommand: ;sendet 6 Befehlsbytes [SD_Addr..SD_Addr+5]
sbi PORT_SPI,SEL ;Chip NICHT selektieren
out SPDR,r2 ;$ff senden
sbis SPSR,SPIF
rjmp PC-1
cbi PORT_SPI,SEL ;Chip select
lds r16,SD_Addr+0 ;1. Byte lesen
out SPDR,r16 ;und senden
lds r16,SD_Addr+1 ;nächstes Byte schonmal einlesen
sbis SPSR,SPIF ;warten bis erstes fertig gesendet wurde
rjmp PC-1 ;
out SPDR,r16 ;2. Byte senden... usw..
lds r16,SD_Addr+2
sbis SPSR,SPIF
rjmp PC-1
out SPDR,r16 ;3
lds r16,SD_Addr+3
sbis SPSR,SPIF
rjmp PC-1
out SPDR,r16 ;4
lds r16,SD_Addr+4
sbis SPSR,SPIF
rjmp PC-1
out SPDR,r16 ;5
lds r16,SD_Addr+5
sbis SPSR,SPIF
rjmp PC-1
out SPDR,r16 ;6
sbis SPSR,SPIF
rjmp PC-1
;auf Antwort Warten
ldi r17,10 ;Zähler für Anzahl der Versuche
wr: ;Auf Antwort warten..
out SPDR,r2 ;Takt für eingehendes Byte erzeugen
sbis SPSR,SPIF
rjmp PC-1
in r16,SPDR ;empfangenes Byte lesen
cpi r16,$ff
brne weiter ;Byte nicht $ff, dann fertig
dec r17 ;Zähler schon bei 0?
brne wr ;nein, dann weitere Bytes lesen
weiter:
ret ;empfangenes Byte in r16, bei Timeout stets $ff
Hier die Initialisierungsroutine:
SD_Init:
sbi PORT_SPI,SEL ;Chip NICHT selektieren
;## 80 Clock-Pulse senden
ldi r17,$0a ;Zähler für zu sendende Bytes
clkLoop:
ldi r16,$ff
out SPDR,r16 ;$ff senden
sbis SPSR,SPIF
rjmp PC-1
dec r17
brne clkLoop
;## CMD 0 senden
ldi r16,$40 ;Befehl
sts SD_Addr+0,r16
sts SD_Addr+1,r1 ;Adressbytes..
sts SD_Addr+2,r1
sts SD_Addr+3,r1
sts SD_Addr+4,r1
ldi r16,$95 ;Prüfsumme
sts SD_Addr+5,r16
rcall SD_SendCommand ;Befehl senden
cpi r16,$01 ;Idle-State?
breq SD_OK1 ;Ja, dann weiter
//**Fehlerbehandlung*** ;Nein, Fehlermeldung
ret ;und Abbruch.
SD_OK1:
;## CMD 1 senden
ldi r16,$41
sts SD_addr+0,r16 ;Befehl
sts SD_Addr+5,r2 ;Prüfsumme auf $ff
clr r18 ;Zähler für Anzahl der Versuche
clr r19
cLoop:
rcall SD_SendCommand ;Befehl senden
cpi r16,$00 ;Init erfolgreich?
breq SD_OK2 ;ja, dann weiter
dec r18 ;nein, dann dec(Zähler)
brne cLoop
dec r19
brne cLoop ;
;Zähler bei 0 angekommen: Fehler...
//**Fehlerbehandlung*** ;Fehlermeldung
ret ;und Abbruch.
SD_OK2:
;Alles OK!
ret
Hallo Johannes
Ich hoffe, du verstehst etwas C. So dürfte es dir nicht mehr schwer
fallen deinen Code in Assembler zum laufen zu bringen.
Gruss, Daniel
//**********************************************************************
********************
// MMC Kontrollieren und korrekt Einstellen
//**********************************************************************
********************
int MMC_0_Check (void)
{
// Karte eingelegt?
if (MMC_0_io_CDS()) // Ist eine Karte eingelegt?
{
MMC_0_SPI_Modus(); // Karte in den SPI Modus umschalten
if (MMC_0_Kommando(0x40, 0x00, 0x95) == 0x01) // Karte Reseten
{
if (MMC_0_Init()) // Karte initialisieren
{
// Karten CRC ausschalten
if ((MMC_0_Kommando(0x7B, 0x00, 0x00) == 0x00))
{
// Karten Blocklaenge 512
if ((MMC_0_Kommando(0x50, 0x0200, 0xFF) == 0x00))
{
MMC0_Status = MMC_CARD_OK;
return TRUE;
}
}
}
}
}
return FALSE;
}
//**********************************************************************
********************
// Karte in den SPI Modus umschalten
//**********************************************************************
********************
void MMC_0_SPI_Modus (void)
{
MMC_0_io_card_select(MMC_CARD_DESELECT);
// Damit der User mehr Zeit hat, die Karte in den
// Kartenslot zu schieben
for (int x = 0;x < 40000; x++) {spi0_send_receive (0xFF);}
}
//**********************************************************************
********************
// MMC Initialisieren
//**********************************************************************
********************
int MMC_0_Init (void)
{
int c;
for (c = 0; c < 0xFF; c++)
{
if (MMC_0_Kommando(0x41, 0x00, 0xFF) == 0x00)
{
return TRUE;
}
}
return FALSE;
}
//******************************************
// Kommandos an die MMC senden
//******************************************
int MMC_0_Kommando (unsigned int Kommando, unsigned int Adresse,
unsigned int CRC)
{
int out;
MMC_0_io_card_select(MMC_CARD_SELECT);
spi0_send_receive (0xFF);
spi0_send_receive (Kommando);
spi0_send_receive (Adresse >> 24);
spi0_send_receive (Adresse >> 16);
spi0_send_receive (Adresse >> 8);
spi0_send_receive (Adresse);
spi0_send_receive (CRC);
spi0_send_receive (0xFF);
out = spi0_send_receive (0xFF);
MMC_0_io_card_select(MMC_CARD_DESELECT);
return out;
}
Ja, ich kann den Code gut nachvollziehen, finde aber leider keine
Unterschiede in der Vorgehensweise...
habe mal weiter getestet:
wenn man keine karte einsteckt, dann bekomme ich FF zurück
leider kann ich an stelle von CMD0 alles mögliche senden: andere
Befehlscodes oder eine Falsche Prüfsumme liefert trotzdem den wert 1
mein spi ist folgendermaßen initialisiert:
ldi r16,(1<<SPE)|(1<<MSTR)|(1<<SPR0);MASTER, Prescaler: 16
out SPCR,r16
hallo,
vielleicht schon zu schnell die initialisierung!!!
ldi temp1, 0x53
out SPCR, temp1
ldi temp1, 0x00
out SPSR, temp1 ;vorteiler 128
wenns dann nit klapppt muss man deine routine mal anschauen oder deine
hardwarwe!!
Die eingänge der Karte sind alle über Spannungsteiler mit dem ATMega8
verbunden. Data-out liegt direkt an. Versorgt wird die Karte über einen
Spannungsregler (3.3V)
Ich habe alles nochmal ausgiebig getestet:
Wenn man die Karte rinsteckt, und die 80 clock-Pulse gesendet hat und
den CMD 0 gesendet hat, dann bekommt man 1 als Rückgabewert.
Wenn ich nun einen Falschenbefehlscode sende, bekomme ich eine 5 zurück.
Das würde bedeuten, das "Illegal Command"-Bit und das "Idle" bit sind
gesetzt -> übertragung macht keine Probleme.
jedoch das Senden des CMD1 sendet immernoch eine 1 zurück, egal wie oft
ich es wiederhole. Zum Ausprobieren habe ich 2 verschiedene Karten.
Jetzt das komische: einmal habe ich es geschafft! es kam schon nach
kurzer Zeit eine 0 zurück!
auch wenn ich jetzt einen ungültigen befehl sende, bekomme ich nur noch
eine 4 zurück, also das "Idle" Bit ist tatsächlich gelöscht.
Dann hab ich die Schaltung neu in betrieb genommen, also Strom aus,an
und schon stand ich vor dem alten Problem..
Benutz mal anständige Pegelkonverter für MISO,MOSI,SCK,CS.
Ich hab mittlerweile 10 verschiedene MMC/SD
am laufen. Von 16MB bis 4GB.
Probleme wie du sie hast kenne ich gar nicht.
holger wrote:
> Benutz mal anständige Pegelkonverter für MISO,MOSI,SCK,CS.
Hat er doch. Ich benutze bei meinem AVRNAS auch Spannungsteiler, und das
Dingen fluppt sehr gut...
Ich kann mich nicht mehr genau erinnern, aber mein C-Code der
Initialisierung sieht so aus:
1
#define CMD0 (0x40+0)
2
#define CMD1 (0x40+1)
3
4
voidspi_putb(uint8_tb)
5
{
6
7
SPDR0=b;
8
while(!(SPSR0&(1<<SPIF0)));
9
}
10
11
uint8_tsd_cmd(uint8_tcmd,uint32_targ)
12
{
13
uint8_ttemp;
14
15
spi_putb(cmd);
16
spi_putb((uint8_t)(arg>>24));
17
spi_putb((uint8_t)(arg>>16));
18
spi_putb((uint8_t)(arg>>8));
19
spi_putb((uint8_t)(arg));
20
spi_putb(0x95);
21
22
while((temp=spi_getb())==0xFF);
23
24
returntemp;
25
}
26
27
voidsd_init()
28
{
29
//....
30
//select
31
while(sd_cmd(CMD0,0)!=1);
32
while(sd_cmd(CMD1,0)!=0);
33
//deselect
34
//...
35
}
Ich sende CMD0 also so oft, bis das Responsebyte stimmt. Ich kann mich
glaube ich daran erinnern, dass die Karte in der ersten Schleife auch
einen Moment verharrte. Vielleicht mal ausprobieren.
>Hat er doch. Ich benutze bei meinem AVRNAS auch Spannungsteiler, und das>Dingen fluppt sehr gut...
Schön für dich. Was macht das Teil bei 8MHz SPI ?
Bringen alle SD/MMC wirklich mindestens 3V am Ausgang
damit der AVR das auch noch als High erkennt ?
holger wrote:
> Schön für dich. Was macht das Teil bei 8MHz SPI ?
Läuft. Als Spannungsteiler benutze ich 1k8/3k3 Ohm
> Bringen alle SD/MMC wirklich mindestens 3V am Ausgang> damit der AVR das auch noch als High erkennt ?
Jo.
>> Bringen alle SD/MMC wirklich mindestens 3V am Ausgang>> damit der AVR das auch noch als High erkennt ?>Jo.
Sorry, das wusste ich nicht ;)
Welche ALLE SD/MMC schaffen das bei dir ?
holger wrote:
> Welche ALLE SD/MMC schaffen das bei dir ?
Versteh ich jetzt nicht. Wenn die Betriebsspannung 3,3V ist, dann wird
ein High-Pegel heutzutage auch etwa um 3,3V liegen...
>Versteh ich jetzt nicht. Wenn die Betriebsspannung 3,3V ist, dann wird>ein High-Pegel heutzutage auch etwa um 3,3V liegen...
Versteh ich jetzt auch nicht, das es immer wieder Probleme
mit diesen Primitiv-Schaltungen gibt. Das ist mir völlig
unverständlich !?
Meine positiv Liste mit richtigen Pegelkonvertern:
MMC
===
Canon 16MB
extrememory 32MB
SanDisk 128MB
MMC plus extrememory 256MB PREMIUM
MAXflash 1GB MMC PLUS
SD
==
Mini SD Nokia 64MB
SD takeMS 128MB
SD Toshiba 128MB
SD SanDisk 256MB
SD hama 256MB
SD NoName 60x 512MB
SD Qimonda 512MB
SD Kingston 512MB
SD Stone 1GB
SD extreMEmory 1GB PERFORMANCE
SD CnMemory 1GB Firstclass Silver 60x
SD memorex 2GB
SD NoName 2GB XF00068850 (Reichelt)
SDHC Toshiba 4GB
10 Stück davon habe ich selbst ausprobiert, der
Rest wurde als positiv gemeldet.
> Bringen alle SD/MMC wirklich mindestens 3V am Ausgang> damit der AVR das auch noch als High erkennt ?
Ich hatte in meinem ersten Layout ärgerlicherweise auch in der MISO -
Leitung einen Spannungsteiler drin, hat nicht die Bohne gestört, hat
trotzdem einwandfrei funktioniert. :)
ich bin grad auch dabei ne sd/mmc karte anzusteuern. außer der karte und
nem resettaster hängt im prinzip nix am µc. steck ich die karte rein und
drücke reset bekomme ich auf den initbefehl auch ne falsche antwort.
erst nach dem zweiten reset läuft alles ohne problem. keine ahnung warum
und ich hab schon alles ausprobiert um das zu ändern. ohne erfolg.
das mit den pegelwandlern halte ich für nicht notwendig. bei mir läuft
das mit spannungsteiler und 10Mhz SPI-frequenz ohne probleme
@fubu1000: Ja, das wäre Nett, wenn du mir dein Assemblerprogramm mal zum
Testen geben könntest.
@Thilo M.: Bei mir ist der MISO Eingang direkt mit der Karte verbunden.
Ich glaube nicht, dass das Problem in meiner Software zu suchen ist, da
ich ja Befehle senden kann und auch die zu erwarteden Antworten von der
Karte bekomme. Das Problem ist nur, dass die Karte nicht aus ihrem
Idle-Zustand heraus will.
Ich benutze SD-Karten der Firma Kingston und Jenoptik
>Bei mir ist der MISO Eingang direkt mit der Karte verbunden.
Bei mir jetzt auch ;)
Wollte nur sagen dass der µC-Eingang schon recht kleine Spannungen als
high erkennt. Muss mal testen wo die Grenzen sind (ob's Datenblatt recht
hat) ..
gast wrote:
> ich bin grad auch dabei ne sd/mmc karte anzusteuern. außer der karte und> nem resettaster hängt im prinzip nix am µc. steck ich die karte rein und> drücke reset bekomme ich auf den initbefehl auch ne falsche antwort.> erst nach dem zweiten reset läuft alles ohne problem. keine ahnung warum> und ich hab schon alles ausprobiert um das zu ändern. ohne erfolg.> das mit den pegelwandlern halte ich für nicht notwendig. bei mir läuft> das mit spannungsteiler und 10Mhz SPI-frequenz ohne probleme
Wie schon gesagt, es kann sein, dass man CMD0 in einer Schleife so oft
senden muss, bis die SD Karte aus dem Idle heraus ist. Ich weiß es aber
nicht mehr, es stand aber in meinem Code drin (oben). Und das beste:
Dieser Code funktioniert.
@simon küppers: bei mir aber nicht. ich hab CMD1 in ner schleife, so
dass es öfter gesendet wird, und diese schleife schonmal bis 100
gesetzt. immer das gleiche, erst nach dem zweiten reset gehts. vieleicht
liegts an der karte
Hallo
Euer Initialisierungsproblem liegt darin, dass z.T. selbst die gleiche
Karte z.T. unterschiedliche Zeiten hat beim initialisieren. Entweder
nimmt man es sehr gemütlich, oder man wartet so lange, bis der Befehl
die korrekte Antwort zurück gibt. In der Funktion MMC_0_Init(void) (C
Code fast am anfang der Seite) kannst du sehen, dass max. 255 mal das
Kommando gesendet wird. Da kam es schon mal vor, dass der Befehl 7mal,
1mal, 30mal aufgerufen wird.
Genauso gibt es Fehler, wenn du eine Card detect Funktion einbaust und
man die Karte zu initialisieren beginnt, wenn der Benützer gerade die
Karte einlegt. Da heisst es ebenfalls Geduld. Entweder nicht sofort die
Karte zu Initialisieren oder man lässt ein paar dummy Daten länger über
den SPI zur Karte senden um die Karte in den SPI Modus zu schalten.
Beides bewirkt eine Verzögerung.
Sollte die initialisierung fehlschlagen, unbedingt mit dem SPI Modus
umschalten wieder beginnen. Gasz billige Karten, schaffen ab und zu
nicht mal das und dann kann man lange versuchen zu initialisieren.
Sollte jemand auch ein Filesystem verwenden, dann die Karte auf keinen
Fall mit Wi***ws Formatieren. Nimm Li**x, dann ist auch ein rechter MBR
(Master Boot Record) drauf. Sonst gibt es so Geduldspiele wie: such den
Anfang der Partition. Je nach OS Version ist es etwas besser oder
schlechter.
Gruss, Daniel
hallo johannes,
sry das ich mich jezt erst wieder melde, hatte viel zu tun.
wenn du noch interressiert bist, dann schreib deine email addresse hier
ins forum. dann kann ich dir den code schicken und womöglich
weiterhelfen!!!
gruss
@Daniel Schwab:
Ich habe versucht den Befehl CMD1 über 65536 mal zu senden und es kommt
nichts bei heraus..
@fubu1000:
meine EMail Adresse : Johannes-Thull@web.de
Hallo,
hab ein ganz ähnliches Problem:
Die hardwaremäßige Anbindung scheint zu funktionieren (zumindest lässt
sich den Signalen gut hinterheroszillographieren), aber:
Auf CMD0 antwortet meine SD-Karte (1GB, Platinum, quasi NoName von
Reichelt) mit 00000101, also "Idle" und "Illegal Command".
Sowohl das ausgehende CMD0, als auch die Antwort kann ich mit dem
Oszillographen beobachten und habe die Bits von Hand nachgezählt - die
stimmen mit dem überein, was mein Atmega168 behauptet.
Habt Ihr einen Verdacht, woran es liegen könnte, dass die Karte nicht
mag?
Danke
Mathias
Hi!
ich hatte mal das selbe Problem nachdem ein falscher Befehl ,durch ne
kalte Lötstelle,gesendet wurde. Aus Verzweiflung habe ich sie in den PC
gesteckt, die Eigenschaften und den Inhalt betrachtet -nichts
auffälliges.
Danach in meinen Kartenhalter und was soll ich sagen, die Karte geht
heute noch->?????
Zu den Pegelkonvertern, manche Karten haben so schwache Ausgänge das der
AVR, wenn an 5V, die Signale manchmal nicht sauber empfängt. Seit ich
einen drinn habe, habe ich auch keine Probleme mehr.
Was mir an deinem Code auffällt, du sendest kein Dummybyte bevor du die
Daten empfangen willst. Auch ans Ende jeder Übertragung gehören min 8
Takte besser 16.
Der SPI Takt darf, bis CMD1 ok ist, nicht über 400kHz sein.
Viel Erfolg, Uwe
@ uwe
>Was mir an deinem Code auffällt, du sendest kein Dummybyte bevor du die>Daten empfangen willst. Auch ans Ende jeder Übertragung gehören min 8>Takte besser 16.
Meinst du Dummybytes wenn CS High ist ?
Die braucht man nicht.
aha, da sagen die SD Card Datenblätter was anderes. Ist das jetzt von
dir nur eine Feststellung aus der Praxis oder hats du dazu offizielle
Datenblätter die das besagen ?
Gruß Hagen
>aha, da sagen die SD Card Datenblätter was anderes.
Ok, beim Init vor CMD0 muss man das natürlich.
Danach aber nicht mehr.
An welcher Stelle sagen die Datenblätter das man
bei CS High noch takten MUSS ? Es ist wohl eher
das man takten KANN ! SPI halt. Alles andere wäre
bei einer SPI Schnittstelle schlicht Unsinn.
>Ist das jetzt von dir nur eine Feststellung aus der Praxis oder>hats du dazu offizielle Datenblätter die das besagen ?
Das ist eine Feststellung aus der Praxis. Siehe oben.
18 verschiedene getestete Karten und keine Probleme
wenn man bei CS High KEINE Dummys sendet.
Hast du eine Karte wo es nicht so ist ?
Verkauf sie mir !
Ganz einfach, die SD Karte ist vom Takt abhängig, der Takt steuert die
interne FSM. Werden zb. Daten geschrieben so benötigt die Karte einen
Takt und der muß par Zyklen nach dem Senden des Datenblockes
weiterlaufen.
So habe ich die Datenblätter interpretiert.
In meiner mmcSendCommand() Funktion sende ich bei deaktiviertem CS der
Karte erstmal 8 Bits, danach aktiviere ich die SD Karte und sende den
Kommandoblock. Beim Warten auf das Response sende ich weiter immer 0xFF
und warte auf die Antwort der SD Karte. Also VOR und NACH dem
Kommandoblock lege ich schon einen Takt für die Karte an. Und.. das
funktioniert bei mir mir mit allen Karten die ich testen konnte, ohne
die üblichen Fehler bei anderen Libs.
Gruß Hagen
>Ganz einfach, die SD Karte ist vom Takt abhängig, der Takt steuert die>interne FSM. Werden zb. Daten geschrieben so benötigt die Karte einen>Takt und der muß par Zyklen nach dem Senden des Datenblockes>weiterlaufen.
Nein, muss er nicht. Das ist bei SPI NICHT erforderlich.
>Und.. das>funktioniert bei mir mir mit allen Karten die ich testen konnte, ohne>die üblichen Fehler bei anderen Libs.
Welche Karten ? Hast du eine Liste ?
Meine Lib ist keine der üblichen. Siehe Anhang.
Lesen und schreiben von MMC/SD macht OHNE
diese Dummybytes keine Probleme. Bei immerhin 18 Karten.
Da sind ziemlich alte Dinger dabei und moderne SDHC Karten.
Stop mal in MMCCommand hast du
1.) SPI_WRITE(DUMMY_WRITE); noch bevor du das Commando Byte sendest und
dabei schon CS=LOW !? Das widerspricht den SD Card Spezifikationen, also
das CS schon LOW ist beim DUMMY_WRITE.
2.) du wartest auf das Response Byte par Sourcezeilen später. Da sendest
du auch solange das DUMMY_BYTE bis du ein Response bekommst
Und davon rede ich die ganze Zeit. Du musst vor und nach dem Senden des
Commandos auf die SD Karte warten und dabei muß die SD Karte weiterhin
getaktet werden, weshalb auch in deinen Code, weiterhin getaktet wird.
Und auch bei deiner Funktion MMCReadSector machst du das gleiche !
Auch da taktest du die SD Karte solange bis ein Timeout entsteht oder
das gültig Response der SD Karte empfangen wurde. Diese Dummy Writes
sind essentiell nur dazu da das die FSM der SD Karte weiterarbeiten
kann. Denn die SD Karte hat keinen eigenen Takt aber ehrwohl einen
Prozessor, sogar Kryptoprozessor. Der braucht nen Takt ;)
Nicht verärgert sein, aber ist das der Source den du anhängen wolltest ?
"Kennst du deinen Source ?" könnte man versucht sein zu fragen ;=)
Gruß Hagen
>Welche Karten ? Hast du eine Liste ?
Nöö kann aber versuchen eine zu machen, dazu muß ich nur alle Karten
einsammeln. Auf alle Fälle einige Nonames von eBay, überwiegend SanDisk
ab 16Mb aufwärts und par Kingsten (sind doch die grünen) und
ExtremMemory, die ich aber nur noch für die DigiCam benutzen werde, wäre
mir zu schade.
Ach und Nomame MMC Karte, die habe ich geschrottet, bei meinen ersten
Tests ;)
Es ist aber kein Indiz das eine Library sauber funktioniert. Ich halte
mich an die Datenblätter des Standards und das hat gereicht.
So, jetzt kommt die Frage ob ich das Datenblatt noch habe. Sicherlich,
muß aber erstmal suchen immerhin war das vor 2 Jahren.
Gruß hagen
Absatz 4.5. Clock Control im ProdManual von Sandisk Version 1.9.
Anhängen werde ichs hier nicht, es ist eh schon schwierig legal an diese
Datenblätter zu kommen.
In meinem Code sende ich bei CS=HIGH 8 Bits bevor ich das eigentliche
Kommando sende. Laut Spezifikation sollten diese 8Bits aber nach eienr
Aktion gesendet werden. Das spare ich mir.
D.h die besagten 8 Bits bei CS=HIGH die man der Karte nach einer Sequenz
senden sollte mache ich VOR dem senden des nächsten Kommandos.
Gruß Hagen
@ Hagen
>"Kennst du deinen Source ?" könnte man versucht sein zu fragen ;=)
Scheinbar nicht :(
Du hast natürlich recht. Ich hab Unsinn erzählt.
Dieses Dummy vor dem Kommando hatte ich mal entfernt.
Funktioniert bei MMC und einigen noname SD übrigends hervorragend.
Hab ich gerade noch mal ausprobiert. Bei ner Sandisk und Toshiba SD
gehts so gar nicht. Irgendwann muss ich das Dummy wieder eingebaut
haben. Und dann sofort vergessen.
Es funktioniert aber bisher problemlos das Dummy Byte zu senden
ohne die CS Leitung nach der Response auf High zu ziehen.
Vieleicht sollte man nach der Response CS aber besser doch
auf High ziehen, um Ärger mit empfindlichen Karten zu vermeiden.
Meine Karten tun es auch so, aber ich schreibs mir mal auf !
Danke für den Tritt in den Hintern ;)
Holger
Ja CS ist anscheindend egal, es zählen nur die Takte auf der
Clockleitung. Allerdings sollte Dummy=0xFF sein. Laut SD Spec, irgendso
ein inoffizielles Datenblatt, sollte aber CS=HIGH sein, um unnötige
Fehlcodierungen des Commandobytes zu verhindern.
Gruß Hagen
@Johannes: Ja, dass jeder Befehl im Prinzip |0x40 genommen werden muss
ist beachtet - hab es mit den Quellcodes von Ulrich Radig und Roland
Riegel ausprobiert (die tun das ja alles korrekt und sind sehr gut
nachvollziehbar).
Hab in einem Handy noch ne RS-MMC gefunden, die freundlich und zufrieden
antwortet - es scheint also ein Problem mit genau dieser SD-Karte zu
geben - hab mir erstmal noch eine Sandisk-Karte bestellt und werde
schauen, was die so macht.
Wenn die auch nicht klappt, dann muss ich wohl mal drüber nachdenken, ob
ich ein Hardwareproblem habe (Spannungsversorgung oder sowas - die
RS-MMC sind ja im möglichen Spannungsbereich etwas toleranter...).
Oder fällt Euch noch irgendwas ein?
Mathias
Hallo,
habe demnächst auch vor erste Versuche mit SD-Karten zu machen. Eine
Frage dazu:
Man ließt immer wieder von SD-Karten die mit bestimmten Sourcecodes
nicht funktionieren usw. Gibt es eigentlich Sourcecode der mit allen
Karten arbeitet? Oder anders ausgedrückt: Gibt es auch kommerzielle
Software (in Digi-Cams, Kartenlesern usw.) die nicht mit allen SD-Karten
funktioniert?
Ciao
Chris
Ich habe nun mal eine Karte der Marke "Intenso" versucht, und habe die
Karte erfolgreich initialisiert. Deshalb muss es einfach an den Karten
liegen und nicht an meiner Software.
@Chris: Ich denke der Königsweg für SD-Karten auszulesen geht über den
normalen SD-Karten-Bus. Ich denke nicht, dass die SD-Reader an meinem Pc
über die langsamere SPI-Schnittstelle kommunizieren, aber das wäre dann
noch auszuprobieren ;-)
Ich habe bis jetzt keine SD- oder MMC-Karte, die bei meiner Hard- und
Software nicht lief. Ich habe aber keine Lust, mir von allen Herstellern
alle Typen zu Kaufen.
Hallo,
die "normalen" SD-Karten kann ich initialisieren. Hab den
Assembler-Code,
hoffentlich halbwegs verständlich, hier veröffentlicht.
Beitrag "SD-Karte Initialisierung Read Write FAT ATmega8 (Assembler)"
Jedoch eine 4GB (SDHC) Karte lässt sich nicht initialisieren.
CMD0 wird korrekt beantwortet aber bei ACMD41 bzw. CMD1 lautet die
Antwort immer x01.
Werden die SDHC Karten anders initialisiert ?
Bernhard
hallo, unten in de pdf sind die zeiten beschrieben für das ansprechen
der mmc-karte
http://www.mikrocontroller.net/attachment/24687/spitiming.pdf
wer kann mir diese werte unten mal erläutern, verstehe die nicht ganz
mit fixed und multiples usw.
8x4= fixed multiple of 8 clocks
8x= multiples of 8 clock
8 =number of dummy clocks
8 =number of clocks
danke
mfg
> 8x4= fixed multiple of 8 clocks
Es ist eine feste Anzahl an Tackten vorgeschrieben und zwar muss die
Anzahl ein vielfaches von 8 sein. In diesem Fall 8 x 4 = 32
> 8x= multiples of 8 clock
Die Tackt anzahl muss ein vielfaches von auch sein. Wieviel mal 8 Tacke
ist egal.
> 8 =number of dummy clocks
8 Tackte bei denen aber keine Daten gesentet oder empfangen werden.
> 8 =number of clocks
Feste Anzahl von 8 Tackten.
