If it is failing that early then it is likely a problem with your hardware. Like missing pullup resistors.

Hi David,

What pull up resistors are you talking about ? What signals need a pull up resistor ?

Clement

I clicked resolved by mistake...

I set the MISO with the internal pull up resistor (P4REN |= BIT2, P4OUT |= BIT2) but it doesn't seem to change, still not working.

Is the internal pull up resistor enough ? Do i need an external one ?

Clement

The SD card should send a R1 response in reply to CMD0. What are you getting?

Selecting a special function like SPI may disable the internal pullups. You will have to consult the data sheet to see what it says.

Hi,

I tried to put an external pull-up resistor on the MISO pin and nothing changes.

I actually don't get any response from the SD card in rely to CMD0, i get a timeout in the SDSPI driver as if the SD didn't get the CMD0 at all.

For a few SD card, wait_ready in the SDSPIUSCIB.c file returns 0xFF, but on other cards it returns 0x00, with or without the pull up on the MISO pin.

Hi Clement,

Is your problem solved? Do you still need our support

Best Regards

Johnson

It looks like that code sends CMD0 exactly once. I have always written my SD code to retry that command many times. It should only take one but some cards are more compliant with the specification than others.

0xFF is what you should get if no card is attached at all thanks to the pullup. If you get a zero that means the card is responding but it hasn't reached the idle state yet. CMD0 is the command to go to the idle state so a retry would be in order.

Actually, the thing is that it fails even before the CMD0 is sent. The function wait_ready(hwAttrs) returns 0.

So it fails before the txSPI(hwAttrs, cmd) line...

What could prevent the card from going into its ready state ? What does it need to go in this state ?

Thanks for the help !

Hello Johnson,

My problem isn't solved yet, I cliked the "resolve" button by mistake and I can't find a way to cancel that...

I have never done a wait like that. I had to dig out the specification and search for a bit but it looks like the only time the SD card will hold DAT0 low is while it is writing data into memory. But it will still accept commands during that time so including that test before sending every command is wrong.

I have no idea why a SD card would start up in that condition.

Hello again,

The wait is done in the SDSPI driver provided by Texas Instrument. See below about the DAT0 being low.

So I checked the signals to see if there was anything wrong on this level and tehy seem to be ok, a bit of overshoot but nothing too bad. The level of an SD card is (around) 3.3v but the interface I use on the MSP430F5252 is at 1.8v so I need to shift the levels in order to make this work.

Maybe it comes from this level change, you'll find attached the schematic of this part of my product

I monitored the signal on the µSD_MISO/6.6C pin (DAT0 of the µSD) and on some SD, I see the signal go from 0 to 1 when i pull the SD card in and out, but sometimes it doesn't switch and stays at 0... Does it mean that the SD is pulling the DAT0 low or the SD doesn't do anyhing and is not powerd on or something ?

Thanks !

Clement

Ok, that's it. I put a pull up on the other side of the level shifter and it works fine with all the SD I have with me.

Thanks a lot for your help David !

Out of curiosity, if you have an idea about why some of them worked without the pull up resistor ?

Clement

For better understanding see: 

30C3: The Exploration and Exploitation of an SD Memory Card

This talk demonstrates a method for reverse engineering and loading code into the microcontroller within a SD memory card.

https://www.youtube.com/watch?v=ruEn7TE4YMM