SD Karte Read Multple Blocks sendet Nullen ab Block x+1

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Ä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.

[Jim M. (turboj)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Jim M. (turboj)]

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?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Harald (Gast)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

@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 ;)