Hi Neil
268435456 bytes is 256M (I made a mistake in the last post) and it is the value that is calculated from the read CSD [0x2e, 0x00, 0x32, 0x5b, 0x5a, 0xa3, 0xb4, 0xff, 0xff, 0xff, 0x80, 0x0a, 0x80, 0x00, 0x8d, 0xd5].
It seems that it is not read the same when done by windows, where it is correct in the one case.
If one byte 0x00 were to be added before the read data [0x00, 0x2e, 0x00, 0x32, 0x5b, 0x5a, 0xa3, 0xb4, 0xff, 0xff, 0xff, 0x80, 0x0a, 0x80, 0x00, 0x8d] (also the final byte has been deleted) it would then calculate 1990197248 bytes (2G).
Based on your observations uTasker reads some cards and loses a byte. I assume that some of the cards don't have this problem - check the CSD that is read from them (with "info" command) and see whether there is in fact an extra byte at the beginning.
Further mode you also had the case that Windows detected only 255M, which looks as though also Windows did (or could) have the same problem with particular cards (?).
I would do a few more tests to get an idea of whether this changes between mounting (i.e. whether it is consistent for a particular card or whether it changes). I can't explain a lost byte at the moment since the same interface is used to read from the card, whether the CSD is being read or something else.
You coudl also try changing the SPI clock rate to see whether a slower one durting the mounting phase could have an effect.
The part of the code reading the CSD is below:
case SD_STATE_GET_SECTORS:
if ((iActionResult = fnSendSD_command(ucSEND_CSD_CMD9, &ucResult, ucData)) != UTFAT_SUCCESS) { // get card capacity information
if (iActionResult == CARD_BUSY_WAIT) {
return; // read is taking time to complete so quit for the moment
}
fnInitialisationError(0); // the card is behaving incorrectly - stop and try again later
break;
}
uMemcpy(utDisks[0].utFileInfo.ucCardSpecificData, &ucData[2 - SD_CONTROLLER_SHIFT], 16); // back up the card specific data since it can be of interest later
if (ucData[2 - SD_CONTROLLER_SHIFT] & HIGH_CAPACITY_SD_CARD_MEMORY) { // high capacity
utDisks[0].ulSD_sectors = (((ucData[9 - SD_CONTROLLER_SHIFT] << 16) + (ucData[10 - SD_CONTROLLER_SHIFT] << 8) + ucData[11 - SD_CONTROLLER_SHIFT]) + 1);// SD version 2 assumed
utDisks[0].ulSD_sectors *= 1024; // the number of sectors on the SD card
}
else { // standard capacity
utDisks[0].ulSD_sectors = ((((ucData[8 - SD_CONTROLLER_SHIFT] & 0x03) << 10) + (ucData[9 - SD_CONTROLLER_SHIFT] << 2) + (ucData[10 - SD_CONTROLLER_SHIFT] >> 6)) + 1);// SD version 2 assumed
utDisks[0].ulSD_sectors *= (1 << ((((ucData[11 - SD_CONTROLLER_SHIFT] & 0x03) << 1) + (ucData[12 - SD_CONTROLLER_SHIFT] >> 7)) + 2)); // the number of 512 byte sectors on the SD card
if ((ucData[7 - SD_CONTROLLER_SHIFT] & 0x0f) == 0x0a) { // 1024 byte block length indicates 2G card
utDisks[0].ulSD_sectors *= 2;
}
}
fnMemoryDebugMsg("\r\n");
You could try repeating this a few times to see whether the result varies (unreliability somewhere). It would also be interesting if some card have the problem and others never do.
You could also send me a 'bad' card because I could test it with different processors via SPI and also SDHC to see whether I can identify what is going on and possibly a workaround (?)
Regards
Mark
