SDHC cards not mounting SD cards fine

[JerryR]

I'm using drivers from Brush Electronics which should be compatible with both SD and SDHC cards. SD cards mount fine and are fully functional. All SDHC cards fail to mount. I need a little help from the group with what might be the cause of this issue. Andrew at Brush Electronics suggests that the problem might be no pull-up on the card's DO line or "cheap SDHC cards" and apparently has no other suggestions.

My hardware operates at 3.3v and I have pull-up on the card's DO line and we've tried several brands of SDHC cards without success.

Anyone have any other suggestions?

Thanks for the group's help!

[Ttelmah]

Do you have the reasonably large capacitor with good ESR close to the card?. SDHC cards, pull noticeably more current than SD, and maintaining a smooth supply is vital. The instantaneous current pulses needed are very high, so good decoupling close to the card is vital. A class 10 card can draw pulses up to 100mA...
You are sure you have SDHC, not XC?. XC cards use ExFAT not FAT32.
Generally the output drivers of the higher class number cards do give faster edges to the signals, so the board layout becomes more critical.
What PIC?. 3.3v or 5v?. How are you doing the level conversion if the latter?.
What error does the card report when you try to mount it?.

[JerryR]

Ttelmah:

I'll take a look at the power to the SD card to see how much "wiggle" is in the supply during SPI traffic. We have a 0.1uF close to the SD socket.

Using a PIC18F87J60 at 3.3 volts, so no conversion should be necessary. I'll look to see if I can see specific errors reported.

Thanks for your valuable input Ttelmah.

Jerry

[Ttelmah]

If you look at Brush Electronics notes they recommend a 22uF as close to the SD as comfortable, as well as the 0.1uF.

[newguy]

I was going to say 0.1uF isn't nearly big enough but TTelmah beat me to it. 22uF with a 0.1uF (both ceramic) is what I use and I haven't had issues with any microSD card I've tried yet.

The only issue I had with Andrew's driver wasn't actually caused by his driver. The CCS version I was using (PCD - for dsPICs) wasn't alerting to an error - something was undeclared and the compiler a) wasn't telling me, and b) successfully compiled anyway, even though it was supposed to be a fatal error.

[JerryR]

Hello guys:

Well, just to be on the safe side, I bypassed with a 22uF low ESR tant. and a ceramic 0.1uF in parallel on top of the SD socket pins. Sorry to say, no difference.

SDHC cards produce: "Error trying to mount SD card. 12FAT at sector 0".

[Ttelmah]

Are you sure the cards have been formatted FAT32, not exFAT?.

The standard for years has been FAT16 for small cards, then FAT32 for larger ones. However with the introduction of the SDXC standard, exFAT appeared. This gives problems with a lot of devices that don't support it. So for instance to use the cards on a Raspberry Pi, you have to reformat to FAT32. Same applies on the Mac!...
How big are the cards?. Windows now defaults to using ExFAT for cards larger than 32GB. Have a look at this thread, which has links to formatters that will do FAT32:

<http://www.tomshardware.co.uk/answers/id-1726154/format-64gb-card-exfat-fat32.html>

The error is what you would get if the PIC can't recognise the format.

[JerryR]

Interesting Ttelmah. That sure would be great if it's a formating issue. I believe the failing cards are all 8Gb SDHC.

Thanks

[Ttelmah]

I would run a tester on the cards involved.
There are a _lot_ of fake cards around. Some people talk about 10% of the cards currently being sold. Even some well known retailers have found themselves selling faulty cards....

[Ttelmah]

Just tried two SDHC cards using the Brush drivers unmodified (I'm normally running with modified I/O routines), on a PIC 24FJ256GB606. Both read and write fine. One is a PQi 8GB, and the other a Kingston 32GB. I'm running the SPI at 16Mhz after initialisation.

So you have something wrong.

Try stripping your code right down, and just doing a mount. What F_RESULT code do you get from this?.

[benoitstjean]

If I may add my two cents since I've been using Brush Electronics' driver since 2014...

I have tested initially with SD cards just so I could get it to work but a few days later, went to microSDHC cards and that's what I have been using since 2014 without any issues.

The only problems I have encountered were due to either bad cards or corrupted FAT tables which made the card either not initialize or initialize but not write anything to the card. But that is very seldom. There are ways to making sure the card is always working (e.g. create a blank file and read/write it upon booting for instance).

The max you can use is 32GB as 64GB and above require a license from Microsoft I believe. I had asked Andrew in the past and that was along the lines of his answer.

I have tested all cards ranging from 512MB to 32GB and they all worked. At the moment, my standard is a 32GB.

I've used this driver with the PIC24HJ128, PIC24HJ256 but now my standard is the PIC24EP512.

Things to check:

1) Formatting the card on a PC (first thing that came to mind).

2) You haven't specified if it's standard SD or micro SD but going to microSD implies that the socket is physically different therefore the pinout order will also change. I have run into that issue where I designed a PCB using one socket and a year later for the next rev, DigiKey discontinued the socket and I had to find another one. Turns-out the pins on the replacement one were all shuffled around therefore I had to re-design a PCB just to accomodate the new microSD socket. Make sure the pin position is correct.

3) Is the SPI port tied to the card shared with another device?


Its been a while since I've instalelled the driver in my code and I haven't had to touch it since I got it to work so I don't remember the roadblocks I hit when going about the implementation.

Monday when I get to work, I'll check here if you're still having issues and if yes, I'll check my schematics.

Anyways, just my two cents...


Ben

[Ttelmah]

The only issues I had with the drivers were an error in the pointer handling on the DsPIC's with modern compilers. Funnily in the particular area concerned the same code from the PCH version worked fine!... This however shows at a different point to this problem.

Above 32GB, with Windows, all cards switch to ExFAT, rather than FAT16/32. There is actually nothing to stop you reformatting SDXC cards FAT32 (except Windows will try to force you to use ExFAT). Quite a few third party packages can reformat the cards this way, and a lot of devices require them formatted this way to work (as already mentioned the Raspberry Pi for example - though you can now add an ExFAT driver to this, and a lot of cameras etc..).

On FAT32, MS licensed the handling of long file names, but the actual file system was deemed in court, to be based on existing technology, so couldn't be licensed. This is why the drivers won't handle long file names, but can handle FAT32 fine.