µTasker Forum
µTasker Forum => utFAT => Topic started by: neil on March 09, 2015, 03:15:55 PM
-
Hi Mark,
I am using V2.01 with the processor 52259 , and purchased 20 new 2GB Transcend micro sd cards . When I used (after being formatted on the computer for FAT32) the utFormat or utReformat about 8 of them never formatted. I know my board is ok as I can put a card i know that works in the board. I poll the card with the following command every second.
if (!(ptrDiskInfo->usDiskFlags & DISK_MOUNTED))
...
Regards
Neil
-
Hi Neil
Are here any timeouts or error messages for the cards that don't format, or don't complete their formatting?
Can you find the state of iMemoryState when it stops?
It moves through the states
#define STATE_FORMATTING_DISK_1 20
#define STATE_FORMATTING_DISK_2 21
#define STATE_FORMATTING_DISK_3 22
#define STATE_FORMATTING_DISK_4 23
#define STATE_FORMATTING_DISK_5 24
#define STATE_FORMATTING_DISK_6 25
#define STATE_FORMATTING_DISK_7 26
#define STATE_FORMATTING_DISK_8 31
#define STATE_FORMATTING_DISK_8A 32
#define STATE_FORMATTING_DISK_9 33
#define STATE_FORMATTING_DISK_10 34
#define STATE_FORMATTING_DISK_11 35
so knowing in which state it stopped coud be helpful (also to see if it is the same for each card with the difficulty).
After completing formatting the mounting process re-starts - if the formatting actually terminated but the mounting fails (due to the format data not being read back correctly) the card would also not be ready. In thsi case the question woudl be at what point during mounting does it abort?
Regards
Mark
-
Hi Mark
It gets stuck at on part STATE_FORMATTING_DISK_8
Regards
Neil
-
Hi Mark,
Any luck with this?
Regards
Neil
-
Hi Neil
Since I can't reproduce the problem and also it looks to be restricted to certain SD cards the best that I can do is explain what could be reasons for it to get stuck in a certain state during (re-)formatting - that is, in state STATE_FORMATTING_DISK_8.
What is happening during this state is that each sector belonging to the FAT is being deleted (written to 512 x 0x00). There are usually 2 FATs so the amount of sectors to be cleared is equal to the number of sectors in the FAT * the number of copies of the FAT.
[A 4G card has typically approx. 15'700 sectors to be deleted in its (typically)2 FATs - see the "info" command for overview of characteristics of the card]
The operation is a "background" operation which means that the system is not blocked when it is taking place. The mass storage task will delete one sector at a time and then the task will be re-scheduled so that it can delete the next one as soon as possible. During the progress there are some *** printed to the debug output so that an idea of the progress can be had. If the reformating doesn't complete I would expect this output to stop and the amount of progress actually made be visible (eg. 20%, 50, 75% of the total). By comparing the case with multiple cards that fail you can see whether it is always at the same point or whether it is more random.
The next question is whether the task is still trying or whether it has given up. In fact I wouldn't expect the task to give up unless there is also a write failure of some sort, which would be accompanied with an error such as "Write error\r\n" or possible "TIMEOUT!!!\r\n"
If there is no such error message (assuming they haven't been disabled) I would expect that the task will be in the active state and writing sectors or waiting for the SD card to inform that it is no longer busy after the previous write. Note that the D card will often be busys for a short time after each sector write so the task quits temporarily and tries again later. This means that the second question is, if no error messages were seen, whether the task is still regularly checking the state of the SD card but can't continue because the SD card always returns that it is busy (forever).
The final possibility is that there were no errors and the SD card is not busy but that the mass storage task has stopped polling/writing the card. This final possibiity would be more likely a SW error since it wouldn't be normal to stop before the process is complete. It is however unlikely that this woud be encountered only by certain SD cards and not by others.
Is it possible to identify which category of problem exists from this?
Regards
Mark
-
Hi Mark,
Thanks for the explanations. In case you get the same issue with other users, would it be useful if I sent you one of the cards so you can have a look? The strange thing is quite a few of the cards we got did format okay , and all were purchased at the same time, and same brand.
Regards
Neil
-
Hi Neil
You are wecome to send me a card that shows a problem so that I can analyse it.
Have you been able to identify whether the problem always occurs at the same place during formatting (eg. the same number of progress *** are seen?
Also, if you try with an older version of utFAT or with a Kinetis (SDHC) instead of the SPI mode is there maybe a difference?
Regards
Mark
-
Hi Mark,
Ive no luck, but I am happy sending you one of the cards. Can you give me the address to send it to (you can email me it if you wish)?
Regards
Neil
-
Neil
The address is at http://www.mjbc.ch/eng/contact.html
Regards
Mark
-
Hi Mark,
Thats it in the post now, hopefully you will get it in a couple of days
Regards
Neil
-
Hi Neil
I have received the 2GByte Transcend card and checked that I could format it normally with the PC (OK)
Then I put it (uSD) in a Kinetis FRDM-K64F and retried using the software from here: http://www.utasker.com/kinetis/FRDM-K64F.html
which operates in SDHC mode. This was also OK.
Therefore I don't have difficulties using the SDHC (4-bit) interface, whereas if you use the M52259 it will be communicating in SPI mode instead.
As reference, this is the "info" command output after formatting on this platform:
SD-card MARK (2008023040 bytes) FAT32
Bytes per sector: 512
Cluster size: 4096
Directory base: 0x00000002
FAT start: 0x0000005f
FAT size: 0x00000ef3
Number of FATs: 2
LBA: 0x00001e45
Total clusters: 0x00077737
Info sect: 0x00000040
Free clusters: 0x00077736
Next free: 0x00000003
CSD: 0x00 0x7f 0x00 0x32 0x5b 0x5a 0x83 0xbd 0x6d 0xb7 0xff 0x80 0x0a 0x80 0x00 0x00
As next step I will repeat with a hardware using SPI mode instead.
Regards
Mark
-
Hi Mark,
Thanks for checking the card. You are right, we are using it with the 52259. Look forward to see the tests on the SPI .
Regards
Neil
-
Hi Mark,
Just wondering if you had a chance to try it using SPI on the 52259?
Regards
Neil
-
Hi Neil
Not yet - I am having some difficulties with work load and would like to first check in SPI mode on the Kinetis and, if it is still Ok, move onto the Coldfire to be able to work out what the difference could be.
Unfortunately my first Kinetis tests failed (with all cards) so I need to work out what the problem is (the board was [partly] damaged recently when I connected something incorrectly so it could be a HW failure).
I expect to be able to continue this evening.
Regards
Mark
-
Thanks for the update Mark
Regards
Neil
-
Hi Neil
I fixed the HW and now have results with a Kinetis in SPI mode:
SD-card MARK (1534066688 kBytes) FAT32
Bytes per sector: 512
Cluster size: 4096
Directory base: 0x00000002
FAT start: 0x0000005f
FAT size: 0x00000ef3
Number of FATs: 2
LBA: 0x00001e45
Total clusters: 0x00077737
Info sect: 0x00000040
Free clusters: 0x00077723
Next free: 0x00000016
CSD: 0x7f 0x00 0x32 0x5b 0x5a 0x83 0xbd 0x6d 0xb7 0xff 0x80 0x0a 0x80 0x00 0x8d 0xe5
Compare with
CSD: 0x00 0x7f 0x00 0x32 0x5b 0x5a 0x83 0xbd 0x6d 0xb7 0xff 0x80 0x0a 0x80 0x00 0x00
as read in SDHC mode; it looks to be shifted.
Notice that the size is huge (1'534 GBytes) and the CSD is different.
The FAT information is the same (since it was formatted by the PC and can be read correctly).
The problem is that when the card is formatted it will be done so based on its size (read from the CSD register) and so will result in a very large FAT and it goes on for a long time and the end result is obviously not correct.
You once had a similar probelm with a shift in the CSD being read - I have one of the cards with this problem somewhere but didn't find it just now. Do you remember whether they it was the same make??
Why some cards read the value shifted (by a byte and seemingly only in SPI mode) is a mystery. I wonder whether information could be received from the manufacturer about this phenomenon?
Otherwise it may be worth working out a technique to identify that the read content is false and correlate to what is expected and thus correct the mis-interpretation. This would allow the correct size to be known and then the formatting to be performed normally (rather than formatting as if it were a >1TByte card).
This would then 'rescue' the cards that you have with this problem.
Could you maybe check that the ones that won't format (seemingly go on forever) read the same CSD and that all 'good' ones read it correctly (without the shift)?
Regards
Mark
P.S: Since I get the same behaviour with a Kinetis it is not processor type related.
-
Hi Mark,
Thanks for the reply.
I will be back in the office beginning of next week so will be able to test the cards I have.
Regarding the previous SD cards that gave the same problem, I cant remember what the manufacturer is, sorry.
Strange with these cards , I purchased 20 (all same brand) from the same supplier, and probably half worked.
Do you think you can have a fix for these?
Regards
Neil
-
Hi Neil
I did a bit of research. The CSD is defined in the "SD Specifications Part 1 Physical Layer Simplified Specification Version 3.01 May 18, 2010" and is 128 bits long. It is however preceeded by a preamble which is also read. Therefore I also checked this and saw the following differences (your card is the third and I have shown it shifted, compensating for the missing start byte):
CSD: 0xff 0xfe 0x40 0x0e 0x00 0x32 0x5b 0x59 0x00 0x00 0x3b 0x37 0x7f 0x80 0x0a 0x40 0x40 0xaf - 8G version 2
CSD: 0xff 0xfe 0x40 0x0e 0x00 0x32 0x5b 0x59 0x00 0x00 0x1d 0x8a 0x7f 0x80 0x0a 0x40 0x40 0xb9 - 4G version 2
CSD: 0xfe 0x00 0x7f 0x00 0x32 0x5b 0x5a 0x83 0xbd 0x6d 0xb7 0xff 0x80 0x0a 0x80 0x00 0x8d (0xe5) - 2G version 1
CSD: 0xff 0xfe 0x00 0x4f 0x00 0x32 0x5f 0x59 0xa3 0xcb 0xff 0xff 0xff 0x8f 0x8a 0x40 0x00 0x29 - 1G version 1
---(start)[ CSD 128 bits (16 bytes) ]
version
access times
speed
CRC-7
Although the first byte is missing it is in fact quite easy to identify that the pre-amble byte is at the wrong location. Also the content can be checked using the CRC-7 at the end to be absolutely sure.
Just after reading the CSD into the buffer called ucData[] (fnSendSD_command(ucSEND_CSD_CMD9, &ucResult, ucData))) I have added this code:
#if !defined SD_CONTROLLER_AVAILABLE
if (fnCheckCSD(ucData) != 0) {
uTaskerStateChange(OWN_TASK, UTASKER_ACTIVATE); // schedule the task to retry
_return; // not recognised or there was a CRC error
}
#endif
The routine fnCheckCSD() checks for a shifted start and corrects it in the buffer if found. It also checked the CRC-7 of the content. In case the CRC-7 were bad it would repeat the read until it is correct.
This routine is below and can be located anywhere before the task in the file mass_storage().
I could then read all of these cards, including yours, and get the correct CSD content. Then I could also re-format your card successfully.
SD-card MARK (2008023040 bytes) FAT32
Bytes per sector: 512
Cluster size: 4096
Directory base: 0x00000002
FAT start: 0x0000005f
FAT size: 0x00000ef3
Number of FATs: 2
LBA: 0x00001e45
Total clusters: 0x00077737
Info sect: 0x00000040
Free clusters: 0x00077735
Next free: 0x00000004
CSD: 0x00 0x7f 0x00 0x32 0x5b 0x5a 0x83 0xbd 0x6d 0xb7 0xff 0x80 0x0a 0x80 0x00 0x8d
This uses the function uReverseMemcpy(), which you may not have in your Coldfire version so I have also added the SW implementation below (Kinetis uses DMA).
Good luck!
Regards
Mark
#if defined SDCARD_SUPPORT && !defined SD_CONTROLLER_AVAILABLE
static int fnCheckCSD(unsigned char ucData[18])
{
unsigned char ucCRC = 0;
int iOffset;
int i, j;
unsigned char ucByte;
if (ucData[0] == 0xfe) { // if a synchronisation is found at the start of the buffer we assume that the SD card returned the CSD content one byte earlier than normal
iOffset = 1;
}
else {
iOffset = 2; // normal location for the content start
}
for (i = 0; i < 15; i++) { // check the CRC-7 of the content
ucByte = ucData[iOffset++];
for (j = 0; j < 8; j++) { // for each bit of the byte
ucCRC <<= 1;
if ((ucByte & 0x80) ^ (ucCRC & 0x80)) {
ucCRC ^=0x09;
}
ucByte <<= 1;
}
}
if ((ucCRC & 0x7f) == (ucData[iOffset] >> 1)) { // check that the received CRC-7 matches with the value calculated for the content
if (iOffset == 16) {
uReverseMemcpy(&ucData[2], &ucData[1], 16); // shift the content to the expected location in case it was originally shifted
}
return 0; // CRC-7 is correct and the data is in the correct location
}
else {
return -1; // invalid CRC-7
}
}
#endif
// uMemcpy() executed in a reverse order to allow shifting buffers to the right
//
extern void *uReverseMemcpy(void *ptrTo, const void *ptrFrom, size_t Size)
{
void *buffer = ptrTo;
unsigned char *ptr1 = (unsigned char *)ptrTo;
unsigned char *ptr2 = (unsigned char *)ptrFrom;
ptr1 += Size; // move to the end of the buffers
ptr2 += Size;
while (Size--) {
*(--ptr1) = *(--ptr2); // copy backwards
}
return buffer;
}
-
Hi Mark,
Thanks very much for sorting this issue, I will update my code when I am back in the office on Monday. Are you planning to update the mass_storage.c file and place on your download page? If so I can simply download the whole lot, saving me modifying your code (in case I update the wrong part of your code)
Many Thanks again
Regards
Neil
-
Neil
It is best if you modify the code since there may be a number of other changes in my code base.
I have however sent my complete mass_storage.c by email as reference.
I also tested your card (sucessfully) on a different board in the meantime (during other work).
Regards
Mark
-
Hi Mark,
That's good news, glad its all working. Just keep or throw away the card I wont need it, as I will now use the cards that weren't formatting.
Thanks again.
Regards
Neil
-
Hi Mark,
Just to let you know, I have tried a card here and works well. I will now try the rest of the bunch, but don't think there will be any problems.
Thanks again for your help
Regards
Neil