SD card initalisation nightmware

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Folks,

I've seen several of you have managed to get SD cards going, but I've been working on this for a week now (learning about SD protocol and FAT to begin with then writing software) and am hoping someone might be able to give me a push with a problem I've been stuck on for two days now.

I have the following:

 //initialization command (74 clock cycles for initialization sequence)
    SendCommand(CARD_CLOCK_INIT, ARG_DONT_CARE,&Response[0]);
// Reset card
    SendCommand(CMD0, ARG_DONT_CARE,&Response[0]);
// Set 2.7-3.3V operation, should also return 0x1AA
    if (SendCommand(CMD8,0x1AA,&Response[0]) == FAIL) 
        return FAIL; 
// Ensure the card's not busy before continuing
 if (sdBusyWait() == FAIL) 
        return(FAIL);

Up to here, all seems perfect. No errors at all:

Then I get here:

// Ask for the CID
 if (SendCommand(CMD2, ARG_DONT_CARE,&Response[0]) == FAIL)  
        return FAIL;

Although I get no errors per se, the data just does not look right. I get this back:

0x1b534d30
0x30303030
0xba00b977
0x1b534d30

As far as I can see from the spec, this should contain various fixed bytes such as ASCII for SD which is 0x5344 - it clearly doesn't.

I then ask for the relative address:

    if (SendCommand(CMD3, ARG_DONT_CARE,&Response[0]) == FAIL) 
        return FAIL;

This always, but always, gives me 0002 in the upper word. No errors, but it seems wrong. As far as I can tell this shouldn't be the same each time?

After that, when I try to initialise the card with the address 2 (or 0x2000) as the value to send with CMD7 (unless I reissue it, when it returns incremental values), I just keep getting non-responses.

I have a Sandisk 2GB micro SD card, I am reasonable sure the set-up is right as my CMD8 always returns the correct value for example.

Anyone able to point me in the right direction please? I have done around a zillion Google searches and tried a gazillion different things; I have a suspicion the issues really start with CMD2 and that return data not being quite right. Why though, and what I should be doing different I am at an utter loss to explain.

Many thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happened when you tried disk_initialize() in mmc.c within FatFs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The data I read looks nothing like what data is actually on the card (I read the war data with hexdump, which is a nifty Linux program.) It comes as mostly zeros.

I have realised that I am not getting a response at all to CMD7.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I say the initialize function in FatFs not only works very well with all cards I've tried but it does a very good job of identifying the problem if there is one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm, it's a CMD7 thing. CMD9, which also needs the RCA, consistently returns data. CMD7 just returns nothing. CMD3 does, it sends incrementally larger RCAs.

I can't even get the Atmel stuff to compile I'm afraid. It's set up for Studio and that piece of **** won't even install on my one remaining Windows computer, let alone run on a proper OS.

I'm close I'm sure of it! I have looked through the Atmel stuff and checked that I'm sending what it does and I have taken other existing code that apparently works and got that to run. Exactly the same result - CMD7 just refusing to return anything which would suggest my RCA is wrong. However, I even tried ploughing through all 0xFFFE addresses and not one of them invokes a response from the card.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DiBosco -

Might not be a bad idea to dig into this...

https://www.sdcard.org/downloads...

and then see what the C code is actually doing.

Just a thought.

Jack

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, had found that a week or so ago, thanks.

I've solved it now. I will write something up and stick it in a PDF now I have learned so much.