SD Card woes

I have a SD card connector attached to a Sharp LH75410 ARM processor via SPI using the SSP hardware. This has been working for ~9 months with a variety of SD and MMC cards. However, recently I have found a couple of SD cards that don't seem to work. I don't mean they don't initialize but that three or four sector reads and writes fail out of a thousand, and the failures don't match the protocol as I understand it. Single sector read CMD17, for example, sometime misses the Format1 response and returns a data token - though sometimes that's gibberish too. CMD24 does something similar.

So I am asking for any experiences with SD cards in SPI mode. What sort of problems there might be. Also for experiences using the Sharp SSP, particularly for SPI usage.

The cards I have tried successfully are SanDisk SD cards of various sizes, Kingston 512MB SD, superspeed MMC+ 1GB , Integral 512 MB SD MLC card, Canon (Ricoh) MMC 16 MB and various other no-name cards.

The cards that fail are a Toshiba 16 MB SD, which seems to have only 14 MB capacity, and a BytesStor 512MB high speed SD.

The set up is a Sharp (NXP?) LH75410 ARM processor running at 51.6 MHz. The SPI is running at 1.84 Mhz except during initialization when it runs at 391 kHz. The card connector is wired via a short cable. The card interface runs from 3V3 that is locally regulated - good for 250mA and looks clean in use. The signal lines has EMC filters at the CPU board because it can be used to interface to other things. This limits the max clock to ~3 MHz. If I fix the clock at 391 kHz this does NOT improve matters though.

The FAT code is based on FatFs R0.02a with my own changes for LFN (and know about the M$ licensing). This doesn't appear to be the issue since it works fine for SanDisk cards Fat12, Fat16 and Fat32 (by reformatting - on SD HC uses Fat32). So I presume the problem to be in my SPI drivers, the physical interface, or some incompatibility in the cards. The code is running from external Flash so it isn't very fast ~ 60kbyte/sec write, but that's plenty.

Clearly I need help - perhaps just therapy!

thanks in advance for any advice Peter

Reply to
Peter Dickerson
Loading thread data ...

SPI

Some cards do misbehave, not following the Sandisk standard to the letter. And that includes Sandisk's own cards themselves too.

The issue is that there's only a small number of OEM manufacturers, and that most cards are rebranded. As an example, I have two Fuji 64MByte SD cards here with identical part numbers yet they're different. The physical contacts on the back are different, the non-working one terminates about 2mm before any other card I have. Thus, it doesn't contact in a push-click socket.

I have about 20-SD and MMC cards here. The latest to misbehave is a 1GB Sandisk.. There's only like 3-cards out of the 20 that misbehave.

Another thing.. During initialisation I read in sector 0 and generate a checksum, and then read it in another 2048 times comparing to the checksum,

1Mbyte. It only takes like 1-2 seconds depending on the card. MMC cards also *seem* to be faster over SPI than what SD cards are.

I suspect that the SD card (4-wire) interface is standard, yet the SPI interface standard is not adhered to by manufacturers.

Reply to
Aly

My experience echoes yours. I'm using the SPI of an NXP LPC2xxx ARM. I'm working with the MicroSD form factor, however. I was given 512MB Kingston cards. I can get them to initialize but will often get only a partial sector read, i.e. I'll read sector 0, and half of it will contain 0xFF. Again, like you, leaving the clock rate at the slow, sub-400 kHz init frequency makes no difference.

I purchased SanDisk cards (512MB, 1GB, 2GB), and can't get a failure.

My card is on a shared SPI bus with four other SPI peripherals (LCD controller, ADC, RTC, Serial EEPROM); I have found that hot-plugging any SD card will corrupt the display, which consumes most of the available SPI bandwidth (not a problem for my device, which isn't mechanically designed for hot plugging, just an interesting symptom).

My gut tells me that the Kingston cards have a problem with the shared SPI. To initialize, the card is clocked without a CS. I wonder if that aspect of the state machine can still be invoked after CMD0.

I've searched extensively on the web for experiences by others; Kingston cards actually tend to have the BEST reputation, so I'm at a loss to explain what's going on with mine...

--Gene

Reply to
Gene S. Berkowitz

Replying to myself since a couple of responses that show up on google groups haven't (yet) propagated to my ISP's news server :-(.

I have now identified the problem with a Toshiba 16M card as mis clocking caused to the cable being too long. A small cap at the card end helped with the prototype. A ByteStor Hi-Speed 512M still shows unresolved problems but they don't seem to be misclocking of responses. To be investigated... I found an unrelated bug in FatFs for FAT32 where creating directories in the root would use the wrong value for .. (cluster number should be 0 even though the root is not usually at cluster 0 on FAT32. As a result I now have SD-HC cards working. OK, I have the one I have working! A SanDisk 4 GB SD-HC, which doesn't work in my laptop even though its only 10 months old.

I still need to get to the bottom of the ByteStor plus why making a directory takes to long (1-2 sec).

Peter

Reply to
Peter Dickerson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.