next topic »

[on:]

So far the highest SCK speed I can use and still ensure reliable data transfer (specifically reading) is 4MHz. At 8Mhz I get about 99% of the data read correctly off the SD card, but every now and then (always in the same place in the file I'm reading) I get a kilobyte or so of 0xFF instead of the actual data. At 16MHz the SD card won't even initialize. So my question is, is there anything I can do to increase the reliability of my connection so that I can get 100% integrity at 8Mhz? I'm running at 3.3v and the SD card is connected to the SPI pins through 2K resistors for current limiting (except for MISO). I'm also using a very basic custom SD library so that I can read as fast as possible. My guess is that the SD card is busy at the times when it gives me 0xFF so checking if it's busy before reading might solve the problem but there doesn't seem to be a busy bit in any of the SPI registers. I already check if bit 7 of the status register is high before proceeding to read anymore data. It might just be that the data is lost somewhere between the SD card and the MCU though. However, the fact that I get bad data in the same place every time really befuddles me.

[Reply #1 on:]

>the SD card is connected to the SPI pins through 2K resistors for current limiting
The serial resistors in the SPI limit the maximum speed (create RC low-pass filter in the signal path).
So from HW point of view this might be the issue..
p.

[Reply #2 on:]

Ha, something inside of me was saying that 2K was too big as well. I'll desolder them and put in some 220 ohm ones tomorrow. But shouldn't they only affect writing? Like I said, there's no resistor on MISO.

[Reply #3 on:]

Just using a seriese resistor is not sufficient for dropping down to 3.3V. You need a potential divider or better a proper level shifter. Just using one resistor will destroy your card.

[Reply #4 on:]

As I mentioned in the original post, I'm running the MCU at 3.3v

[Reply #5 on:]

>I'll desolder them and put in some 220 ohm ones tomorrow. But shouldn't they only affect writing? Like I said, there's no resistor on MISO.

The 220ohm is better than 2k, you may try with it. See the pictures below on the 2k and 220ohm difference. The best solution is none resistors, however..

[Reply #6 on:]

I wasn't sure what the input impedance of the SD card was, hence the resistors. I'll just omit them completely then.

[Reply #7 on:]

Ok, I took out the resistors. Made no difference.

[Reply #8 on:]

What sort of arduino are you using?
It could be that your SD card can't go faster. Have you tried another one?
What class of SD card do you have?

[Reply #9 on:]

I have used many SD card but most of them are not at higher speed.The SD Memory Card includes key enhancements over existing Flash cards. These include cryptographic security, protection of copyrighted data, high-data transfer rate for fast copy/download and high storage capacity in sandisk SD card.

[Reply #10 on:]

>What sort of arduino are you using?
I'm not actually using an arduino. I'm using an ATxmega256D3 on a custom board.

>It could be that your SD card can't go faster. Have you tried another one?
I've tried a 16MB card but it didn't work at any speed (I think it's getting FAT12 formatted instead of FAT16). I also tried a 128MB miscroSD card in an adapter, but it didn't work at any speeds either. My current working card is 512MB if it makes a difference.

>What class of SD card do you have?
If by class you mean speed class then all I know is that there are no high speed marking on it (like these: https://www.sdcard.org/developers/overview/speed_class/host-marks.png). If by class you mean SD vs SDHC vs SDXC, its just plain old SD. The only useful info on the card is SD-M512 which led me to this "datasheet", http://datasheet.octopart.com/SDM512-Toshiba-datasheet-10124.pdf

If the card couldn't go faster then I assume it wouldn't even initialize at 8MHz (like it fails to at 16MHz). The fact that I get 99% of the data back correctly leads me to believe that it's just busy or something and that I have to wait for it. Although it certainly could just be the max SPI speed of the card.

Which leads me to the question, has anyone ever attempted to use an SD card in SD mode (which I assume is faster) on an arduino? Or is it far too complicated/fast for a small MCU to keep up?

Also I just read this: "When the card encounters a data retrieval problem, it will respond with an error response (which
replaces the expected data block)". This is likely whats happening right now. I'll read up some more on it.

[Reply #11 on:]

Sounds like you have lots of software bugs.  You need to look at the SPI mode protocol for access to the SD card.

Much of what you are seeing is due to not following the SD protocol.

For example the way an SD indicates busy for a read is to send repeated 0XFF.  It sends a start of data token when it is no longer busy.

You can't use SD mode since that requires hardware SDIO bus support and the ATxmega256D3 does not have a SDIO bus.