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

OP (Firma: fritzler-avr.de) #5427888
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:
1
uint8_t sd_r_multiblock(uint8_t *buf, uint32_t lba, uint32_t blocks_count, uint16_t block_size){
2

3
  uint8_t cmd_res = 0;
4
  uint32_t offset = 0;
5
  
6
  deprintf("SD - blocks_count(read): %u\n", blocks_count);
7
  deprintf("SD - lba: %x\n", lba);
8

9
  cmd_res = sd_cmd(SD_CMD_READ_MULT_BLOCK, lba);
10
  if (cmd_res){
11
    return sd_errorhandling();
12
  }
13
    
14
  while (blocks_count--){
15
    
16
    // auf das Data Start Token warten
17
    if (sd_waitfor(SD_TOKEN_START_DATA_MULTIPLE_BLOCK_READ) != SD_OK){
18
      deprintf("FAIL SD_TOKEN_START_DATA_MULTIPLE_BLOCK_READ\n");
19
      goto error;
20
    }
21
      
22
    // Daten lesen nach dem Token
23
    sd_read_data(buf + offset, block_size);
24
    
25
    uint8_t blockanfang = *(buf + offset);
26
    deprintf("SD - Blockanfang: %c (%x)\n", blockanfang, blockanfang);
27
      
28
    // nächster RAM schreizugriff ist um block_size weiter
29
    offset += block_size;
30
    
31
    // CRC Bytes wegwerfen
32
    sd_writebytes(0xFF);
33
    sd_writebytes(0xFF); 
34
  }
35
  
36
  cmd_res = sd_cmd(SD_CMD_STOP_TRANSMISSION, 0x00);
37
  if (cmd_res){
38
    deprintf("SD_CMD_STOP_TRANSMISSION - %x\n", cmd_res);
39
    return sd_errorhandling();
40
  }
41
  
42
  return SD_OK;
43
}

*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?
Angehängte Dateien:
#5427962
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.
OP (Firma: fritzler-avr.de) #5428228
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.
OP (Firma: fritzler-avr.de) #5428339
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

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren