mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SD Karte Read Multple Blocks sendet Nullen ab Block x+1


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich schreibe hier grade an einer SPI SD Karten Lib, welche ich unter die 
FatLib von elm Chan geschnallt habe.
Das Ganze läuft auf einem STM32F407.

Single Block lesen und schreiben funktioniert super, das Dateisystem ist 
glücklich.

Jetzt wollte ich das auf Multiple Block lesen aufbohren.
Der erste Multiple Block kommt ganz normal von der SD Karte, aber alle 
Blöcke danach sind genullt! Dabei kommt das Start Token (0xFE), aber 
danach alles 0!

Code:
uint8_t sd_r_multiblock(uint8_t *buf, uint32_t lba, uint32_t blocks_count, uint16_t block_size){

  uint8_t cmd_res = 0;
  uint32_t offset = 0;
  
  deprintf("SD - blocks_count(read): %u\n", blocks_count);
  deprintf("SD - lba: %x\n", lba);

  cmd_res = sd_cmd(SD_CMD_READ_MULT_BLOCK, lba);
  if (cmd_res){
    return sd_errorhandling();
  }
    
  while (blocks_count--){
    
    // auf das Data Start Token warten
    if (sd_waitfor(SD_TOKEN_START_DATA_MULTIPLE_BLOCK_READ) != SD_OK){
      deprintf("FAIL SD_TOKEN_START_DATA_MULTIPLE_BLOCK_READ\n");
      goto error;
    }
      
    // Daten lesen nach dem Token
    sd_read_data(buf + offset, block_size);
    
    uint8_t blockanfang = *(buf + offset);
    deprintf("SD - Blockanfang: %c (%x)\n", blockanfang, blockanfang);
      
    // nächster RAM schreizugriff ist um block_size weiter
    offset += block_size;
    
    // CRC Bytes wegwerfen
    sd_writebytes(0xFF);
    sd_writebytes(0xFF); 
  }
  
  cmd_res = sd_cmd(SD_CMD_STOP_TRANSMISSION, 0x00);
  if (cmd_res){
    deprintf("SD_CMD_STOP_TRANSMISSION - %x\n", cmd_res);
    return sd_errorhandling();
  }
  
  return SD_OK;
}

*la_ubersicht.png*
Hier ist ein Lesezugriff mit 16 Blöcken zu lesen.
Der Block mit dem Pfeil ist der erste Block, der auch ordentliche Daten 
enthält.
Bei den anderen 15 Blöcken sieht man schon die Leere.

*la_block_first.png*
Hier kommt der erste Block, schön zu sehen das 0xFE und danach mein 
lorem ipsum Testtext.

*la_block_second.png*
Auffällig ist auch, dass die MOSI Leitung links LOW ist obwohl hier 
eigentlich keine BUSY Antwort erwartet wird.
Dann gehts jedenfalls high und das STart Token aka 0xFE kommt wieder.
Danach aber 512mal 0x00 ... menno.

Hat da wer ne Idee was da kaputt ist?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Äh kleiner Fehler, das Bild second ist falsch, das ist schon der dritte 
Block.
Hier jetzt der wirkliche 2. Block.

Da ist dann auch der Text zu sehen, es wird HIGH, dann kommt 0xFE und 
dann Nullen.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe da das Problem nicht. Eine SD Karte hat im Block 0 die 
Partitionstabelle und eventuell noch etwas Boot Code, und die nächsten 
paar MB sind Null.

FAT fängt erst viel später an.
Vorsicht: Den Anfang einer Disk sieht unter Windows nur der Admin, und 
er muss auch einen physischen Datenträger und kein logisches Laufwerk 
öffnen.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht um den ersten und zweiten Block des Multiple Block Zugriffs.
Der Dateisystemtreiber will zB ab LBA 0xb050 lesen. (da liegt die lorem 
ipsum Datei rum)

Also nicht den ersten Block auf der SD Karte.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuche mal eine andere Karte. Ich hatte hier auch immer den Eindruck 
das SPI nicht mehr vollständig ausgetestet wird. Welcher Typ ist das 
denn genau?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So läuft jetzt!
Der Fehler war ganz woanders.
Beim schreiben kam das Flag nicht an, dass es eine SDHC Karte ist -> 
beim schreiben wurde in sonstwelche Blöcke geschrieben wegen der anderen 
Adressberechnung.

Dann ließt er natürlich Nullen bei leeren Blöcken.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was du liest kann ich nicht nachvollziehen. Wenn du Zeit hast, dann 
poste bitte als lesbares Hexlisting die jeweils ersten vier Blöcke von 
0, der FAT, des Verzeichnisses und der Datei.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Harald
brauchts ja nicht mehr, funzt ja nun.


Wenn die Lib fertig ist, wird diese natürlich veröffentlicht.
Multiple Block write bringt einen echt dicken Geschwindigkeitszuwachs.
Ist jetzt die Frage ob durch den "vorher löschen" Befehl da noch was 
rauszuholen ist?

Vorher aber noch per #define bestimmbar mit DMA/IRQ aufblasen und 
ordentliche dokumentieren ;)

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.