I got a bunch of cards and ran tests and I'm not sure I understand what I see. They all work for the 1 Mb copy file test (copies a file in fread / fwrites of 512 bytes) using the fatfs with the STLib SD functions. However three SDHC 4Gb class 4 SD cards fail on sdConnect(). I am not sure if it's a problem with HC or with Class 4. One odd thing is that the PNY card is class 4 but it's slower than the SanDisk (this one does not have a class icon but online the model appears as class 2).
The weird thing about these tests is that the 1 MB file copy using fatfs on STLib does not match the supposed speed of the card at all. It seems that the PNY card should be good for my needs but I wish I understood the problem. Could it be a sector size thing? The example I am running is forced to 512 byte single block writes, so maybe if the internal size of the card is larger this is inefficient?
More data: In sdc.c line 186 there's a check for SD V2.0 which passes for the HC cards. Is that supposed to be in braces {} ? Without braces it falls trough and gets reset to SD V1.1 which then sets the ocr to 0x8... and then the initialization loop fails (gets stuck). If I add the braces the init loop passes (but I'm not sure this is the right fix, may be a coincidence).
However, after this fix I see the same behavior I had seen before, which is that the multiblock writes timeout *the first time I write to a given sector*. If I rerun the program it works. In your example, instead of hardcoding 0x10000 I use a macro #define TRY_SECTOR 0x10000 and try different numbers. The first time fails then it works... etc. If I remember correctly I saw the same problem with the multiblock writes using the STLib functions. The reason my copy-file example works is because it forces single block writes (which are probably slower etc).
If you get a 4Gb class 4 card you should be able to reproduce these issues (since I've tried it now with 3 and they all behave the same).
If this is a low level unfixable issue, would it be possible to have a version that uses single block writes? Sort of a hack but it would let me use high capacity cards.
There is already support for single block writes, it is done when you pass an unaligned pointer. You may try it with the current driver, if it works I will add an option to enforce it, anyway, we should try to understand the issue not just find a workaround.
Looking at numbers at least we already have a better performance. About the high capacity cards, I think it is an initialization error, will fix it.
The bad news is that somehow I can't get both ADC3 and SDIO working at the same time (I'm sure it has to do with sharing the DMA2_Ch4_5 interrupt) but I'll keep pouncing at it. There is also a rare case in which fatfs breaks internally (i suspect bad memory access), I think when it's reopening the same filename for writing over and over again some internal structure goes crazy.
Well... I fixed the DMA issue (there was some mismatch in the indexes inside the interrupt) but now I get ff to crash regularly. It's a bit late now but I'll come back to it tomorrow.
I fix the crash too. My file saver thread stack size was too small. Now everything works BUT the 4Gb cards were writing in single block. When buffer the output data they start writing multiblock and fail with the timeout again. Oh well, works for now.
I fixed that error on the trunk. Now I am testing using a SanDisk Class6 8GB card, the test application seems to work, the FatFs demo works too.
Do you have any news? it would be a good idea if you post a small test application that triggers the error on your side so I can do debug using the same code.
