Unable to put some SD cards in idle state

[JerryR]

I've been working on this issue for a solid month, without resolution. Using Brush Electronics SD FAT system with various SD cards. Lower capacity SD cards seem to mount correctly, however I can't seem to get higher capacity SDHC cards to enter idle state.

Please refer to the logic traces at:

https://drive.google.com/drive/folders/0B2OU7T0b3oetUUxaNDNFeEFaZ0U?usp=sharing

Send 80 clock pulses

10 ms later send 40 0 0 0 0 95 (CMD0)

Good card responds with 0x01
Bad cards do not respond with 0x01

There are no other SPI devices enabled on the SPI bus when I'm communicating with the SD card. I have tried multiple card types and manufacturers with the same results.

Does anyone see anything that I'm missing here. I would really appreciate the group's help.

[Ttelmah]

Unfortunately some of the newer cards (a lot), are actually fussier about the init sequence than older cards.
Problem is the Brush driver on faster PIC's, clocks the line too fast for the specification. This is because the required rate is below the minimum that these chips can clock the hardware SPI....
Most older cards don't actually care about the rate.

I got round it by declaring two streams on the same pins. One using the hardware SPI, set to the maximum rate, with 'noinit' specified (SD_SPIHW), and the other software, and the slow initialisation rate (SD_SPISW). I then got rid of the lines in the driver setting the divider, and instead use:

[JerryR]

Ttelmah:

Thanks a lot for your input. That could explain why some cards work and other don't. Currently my clock speed for SPI transfers is around 300Khz. I'll work around with the timing to see if I can encourage the "faster" cards to mount.

I appreciate your (and the group's) input on this. This issue has been a real bear!

Best regards

[asmallri]

[temtronic]

I was thinking like Andrew. Either a missing pullup or pull down resistor, as there NEEDS to be the correct combination. I can't see the card mfrs putting them in (cost 4c), then the interface mfr will 'assume' the card guys do it, sigh.
Hmm, BOTH could have added them, which could cause problems too !!
Best to ring out and confirm EACH line is properly terminated.

Jay

[Ttelmah]

Also though the delay.

I've been caught by this on a couple of recent cards, which don't actually seem to start their wake up till the supply gets well above the point where the PIC starts to wake. I've seen some recent cards take up to 3 seconds to wake!....

The other thing is power. The spikes that can actually be drawn by the cards are large. Insufficient smoothing close to the card, can easily give odd behaviour.

[JerryR]

All:

Thanks for your responses. Please be aware, I have 10K pull-ups as needed. Please consider the logic traces as shown.

I have little doubt that this is a software / compatibility issue. Currently yhe code is stock code sent by Andrew at Brush.

Anyone have any suggestion as to how slow the SPI clocking needs to be to accommodate putting the "faster" cards into SPI mode?

Thanks!

[JerryR]

Ttelmah: Sorry didn't address your suggestions. Power to SD cards have smooth 3.3 volts with 22uF and 0.1uF capacitors on the SD card's supply pins. Power is on constantly (at least 3 seconds) before attempting to mount cards.

Currently, I can only get 2GB SD cards to mount properly. I now have a collection of 30 or so cards which are SD or SDHC 4GB and up that don't mount.

Thanks again

[Ttelmah]

What actual PIC are you using?.

On the fast chips (PIC24 etc.), the hardware can support the lower rates.
Use:

[JerryR]

Ttelmah:

Again, many thanks for your thoughts. Unfortunately, I'm using a PI18F87J60 using external 25MHz crystal, I am using the SPI bus to communicate with an LED driver and EEPROM which both use the hardware SPI lines. Both of these devices are completely disables during SD operations. Additionally, i am only calling SD card routines while working on this SD card issue. Code is now 23,000 lines

Really wished i had started with my own code rather than using the "canned" Brush code. Andrew insists that his stock code is compatible with all SD card formats.

And again, thanks!

[newguy]

[JerryR]

newguy:

It sure is a mystery to me why some cards work fine and consistently and others do not. Consider my logic diagrams and tell me what you see as being wrong. I'd appreciate any and all input.

Regards,

[Ttelmah]

I think the first thing to do is simplify.

Forget about your 23000 lines of code, and run one of the basic SD demos that are supplied with the Brush drivers.
At 25Mhz, the SPI will go down to 390625Hz without problems. Where I had problems was with chips up at 64Mhz, where the low speed was 1Mhz, and some cards did not like initialisation at this rate.

What is supplying the 3.3v?. What current can this deliver?.
Remember an SD can draw 200mA, and generates spikes of much higher currents at nSec timings. They are fussy beasts regarding power.

Do you have all the pullups as shown on Andrew's circuit?. Technically the two on the unused Dat1 & Dat2 lines are _required_ by the spec.

Both grounds connected?.

[JerryR]

Ttelmah:

Yes, re-worked Brush code to work with my hardware and are working with the basic Brush code. All pull-ups are IDENTICAL to brush hardware requirements. Power supply is practically flat during mount attempts.

Thanks

[Ttelmah]

OK. So the code works and the hardware works. You now need to work out what is stopping it when using your original code.