SD card initialisation

Hi,

I'm trying to initialise a 2GB Transcend SD card with an AT89C51AC2.

I send CMD0 and get a 0x01 response. It's initialising...

Then I send 10 CMD55 messages and get no valid response (0xFF) each time. I don't know why I don't get a 0x01 response here until the card has finished initialising?

Sound familiar to anyone?

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn
Loading thread data ...

You send CMD0 and that's fine but you need to send ACMD41 which is CMD55+CMD41 combo. I don't put a limit on the number of times I do this but depend upon a timeout instead. It depends upon the card.

*Peter*
Reply to
Peter Jakacki

Thanks Peter.

It seems that I'm going to get a 0x01 response no matter how many times I issue CMD0.

Also, it seems that I'm going to get an invalid response (0xFF) no matter how many times I then issue CMD55.

Vexing!

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

Yes, of course, but read my previous post. BTW, 01 is the correct response for CMD0 then you move on to Acmd41 not CMD55 .

*Peter*
Reply to
Peter Jakacki

Hi Peter,

Yes, I've issued CMD0, then CMD55 as a precursor to ACMD47. I never got past the CMD55 which results in the repeated invalid response. If I issue CMD0 followed by ACMD47 I get the same invalid responses.

I've managed to get the SD card to respond to an MMC card CMD0 then CMD1 initialisation sequence. That won't do as I'm writing code specifically for an SD card. Crumbs!

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

Hi Peter,

If I misunderstand you correctly this sequence is wrong:

-------------------------------------------------------------------------------

/* Send CMD55 to indicate that next command is application specific */ /* MMC cards do not respond to this command */ cmd[0] = SD_CARD_CMD55; cmd[5] = SD_CARD_CMD55_CRC; retries = 0; while(sd_card_write_command(cmd) != SD_CARD_NO_ERROR) { if(retries++ > 500) { SD_CARD_CS = 1; // Disable SD card return(SD_CARD_NOT_SD); // No response - not an SD card } }

/* Send ACMD41 SEND_OP_COND command */ cmd[0] = SD_CARD_ACMD41; cmd[5] = SD_CARD_ACMD41_CRC; retries = 0; while(sd_card_write_command(cmd) != SD_CARD_NO_ERROR) { if(retries++ > 500) { SD_CARD_CS = 1; // Disable SD card return(SD_CARD_ERROR); // No response } }

-------------------------------------------------------------------------------

What is the CMD55+CMD41 combo if it's not CMD55 (6 bytes beginning 0x37) followed by ACMD41 (6 bytes beginning 0x29)?

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

Uncluttering it and taking it from the top:

Quote from SANDISK Product Manual SD Card V2.2 final

- Section 3.4.1 Power Up

"ACMD41 is a special synchronization command used to negotiate the operation voltage range and to poll the cards until they are out of their power-up sequence. Besides the operation voltage profile of the cards, the response to ACMD41 contains a busy flag, indicating that the card is still working on its power-up procedure and is not ready for identification. This bit informs the host that the card is not ready. The host has to wait (and continue to poll the cards, each one on his turn) until this bit is cleared. The maximum period of power up procedure of single card shall not exceed one second."

All ACMDs are just like a normal command except they are preceded by a CMD55. This is a sequence that only SD cards recognize and is not a feature of MMC just in case you are following MMC specs or some sample code.

ACMD41 for instance is equivalent to issuing CMD55, discard the result, issue CMD41 and return with that result.

BTW, you can ignore CRC as it is not needed in SPI mode, you only need it before you first switch to SPI mode so just use the value 0x95 as the CRC in each command (read the specs).

*Peter*

Murray R. Van Luyn wrote:

Reply to
Peter Jakacki

Typically, you issue a CMD0 20 or 30 times to reset the card (I'm not worrying about MMC cards here). Then you can follow w/ either a CMD8, which distinguishes between SD +/- V2 cards, followed by the CMD55/ACMD41 pair.

Question I have for you is. do you see the exact same behavior whether a card is inserted or not? I have seen what looks like go_idle_state (CMD0) succeed) followed by fails on CMD55, which turned out to be a physical problem w/ the SD socket - broken switch or a piece of junk wedged near the bottom.

Make sure the card is being electrically recognized before you start worrying over the CMD returns.

Best, Tom

Reply to
tporter

Hi Tom,

Well the electrical interface is now 100% correct, thanks to your advice. I'm still getting no further than CMD8. There's still no reply from the SD card no matter how many times it's polled. As far as I'm concerned the signals being issued to the SD card are okay. I'm stumped!

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

I have had problems with 2G cards which I suspect might not be SPI compatible, only SD compatible. However we could all be playing a never ending guessing game unless we have the same details you have such as the schematic and code and details of the exact card.

Of course you should be trying other cards which I assume you have done, it's one of the very first rules of troubleshooting to eliminate various factors and home in on the cause. Try a 1G card or smaller.

*Peter*

Murray R. Van Luyn wrote:

Reply to
Peter Jakacki

All SD cards are supposed to work in SPI mode, even SDHC cards. What problems I have had with entering SPI mode have been due to not sticking to the letter of the spec - seventy odd init clocks,

Reply to
Peter Dickerson

Thanks Peter, Peter and Tom.

I seem to have solved my problem finally. The second bit of a six byte command sequence transmission needs to be high. That makes CMD55 equal to

0x77 and not 0x37 (55) as I had it.

Thanks for all the advice on SD initialisation and debugging guy's.

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

I'm not sure I understand your fix... CMD55 *is* 0x37 in the first 6 bits of the cmdindex -- that is, when you ae setting up the cmdresponse, MCI_COMMAND & 0x003F should be 0x37 for CMD55. No?

Be sure that your RCA used for CMD55 in *idle_state* (send a CMD7 first to check this) will be the card?s default RCA = 0x00000000 (Don't use some of the "fixes" out there - ie RCA=0x00010000) just use

0x0 (for SD cards). In other words, Set_Address should not normally have been run at this point(unless you're up & running & are sending an SDStatus inquiry(ACMD13) so RCA *should be 0x0 - if it's not, certain very bad things will happen -- don't know what they are, but they are likely to be bad.

I've only been wrong ~ 10^6 times this week, & it's still only Monday night.

Best, Tom

Reply to
tporter

Here's another tough one. The file system I'm running over the SD card code is known to be good. Never the less, I'm getting occasional directory/ file corruption when I try to write a file. It's the low-level SD card code that is responsible, but I don't know where I've gone wrong.

To aid in solving the problem I'd like to be able to read raw sectors from the SD card on my Windows sytrem using something like debug. Unfortunately XP won't let me access the SD card directly. Anyone know how I can read the raw SD card sectors on XP?

Regards, Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

It's fairly easy to read raw sectors under XP. Assuming your memory card is physical disk number 3 on your PC, here is some sample code:

h=CreateFile("\\\\.\\PhysicalDrive3",GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

SetFilePointer(h, (sector_number*512), NULL, FILE_BEGIN);

status=ReadFile(h, buffer, 512, &bytesread, NULL);

If you're looking for a utility that will do this for you, I assume that Microsoft's DiskProbe will work on a memory card. DiskProbe is included on your XP installation disc under \SUPPORT\TOOLS. There are also several freeware utilities:

formatting link
I haven't tried any of these personally.

Reply to
Tom

Have you looked at WinHex?

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

Hi Spehro,

I've just loaded up WinHex. It's precisely what I was hoping for. Definitely one for the toolbox. Thanks.

Regards,

Murray R. Van Luyn.

Reply to
Murray R. Van Luyn

An alternative would be to use Linux rather than XP - it is much better for that sort of thing. You can directly access a card as though it were a file, and you can also treat files as devices. Thus you can copy the entire raw card to a file and look inside it. When you've modified the file, you can "mount" it directly without writing it back to the card, and check it that way.

If your main workstation is windows, install VirtualBox and make a USB SD card reader available to the Linux guest.

Reply to
David Brown

A third thumbs up for WinHEX - for computer forensics & SD card low level troubleshooting, this program can't be beat. I really like the root & bootsector templates.

On another note, Linux is great for low-level formatiing since the other disk based utilities leave lots or garbage all over the SD disk

- this (from personal experience) can really screw up troubleshooting.

I like to use dd on Linux to do this though there is a Windose port.

for easing a disk (ie. filling it w/ zeros):

dd if=/dev/zero of=/dev/sda

where /dev/sda is where your card is mounted. This is it's normal location in most Linuxes (or SDA1).

HTH, Tom

Reply to
tporter

I experienced a few bad writes, then began using the optional CRC-7 and CRC-16. I have to re-write occasionally, but no more bad data...

--Gene

Reply to
Gene S. Berkowitz

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.