OSDev.org

Hi,
I am writing my own baremetal OS on an S3C2440 ARM. My SD card is a sandisk 8GB and 4GB. I am able to initialize my SD Card in SD Mode and I am able to read CID, CSD registers etc. The only problem is that once I move to Standby state in CMD3 and send a CMD7 to select the card the card still stays in Standby state. Trying a Deselect and Select card does not seem to work. I tried multiple times to send CMD7 but the card gets stuck in Standby state. If I deselect the card it goes into Idle state. This is very strange as there is no transition to idle state from CMD7. If anybody has solved this problem please do help me.

Thanks,
Gautam.

Have you confirmed you are getting a valid response from CMD3? Namely that the RCA is in the top 2 bytes, and that the CRC error, illegal command and error bits are not set, that the status is something reasonable and that the ready bit is set? You then need to pass the returned value ANDed with 0xffff0000 back to CMD7 (so that you are just passing the RCA bit).

Regards,
John.

There is something strange about CMD3. Initially it gives me a result of 0x00000520 i.e. it is in identify status and is anticipating an APP_CMD. I send another CMD3 and it switches to Standby. The command previous to CMD3 is a CMD2 which is an APP_CMD which gives a CID response. Wonder why the APP_CMD bit was not reset.

*EDIT*: In the spec it says:
Exception in ACMD41
• The response of ACMD41 does not have APP_CMD status. Sending the response of CMD41 in
idle state means the card is accepted as legal ACMD41.
• As APP_CMD status is defined as "clear by read", APP_CMD status, which is set by ACMD41,
may be indicated in the response of next CMD11 or CMD3. However, as ACMD11 and ACMD3 are
not defined, it is not necessary to set APP_CMD status.
• Host should ignore APP_CMD status in the response of CMD11 and CMD3.

So I am ignoring it for now. Not sure about the Identify state.

Also in the subsequent CMD3 I get a 0x00000700 with the RCA values as 0x0000E625.

To send the RCA value I do a (RCA<<16) | 0xFFFFU.

That is odd because I have never had a CMD3 fail to return a RCA or need resending (having tested on several dozen different cards albeit with a different SDHCI controller - the one in the original RPi).

Having said that, after a look through my own code, I realise that its perfectly valid for the response to CMD7 to show either the transmit or standby states, because the status returned in the response is that which the card was in prior to the command being executed. If you issue a CMD13 after CMD7 what do you get?

Other than that, it may be an issue with your timings. Try keeping the clock speed low (400 kHz) throughout the entire initialization process and see if that makes a difference.

Regards,
John.

I issued a cmd13 after cmd7 and lo behold the state has moved to TRANSFER. Let me do some more tests and check. Also is it written in the spec that the state which it shows is not of the present command but of the previous command. I realized now that I have resent RCA because I was in IDENTIFY state which is the previous state.

mindentropy wrote:Also is it written in the spec that the state which it shows is not of the present command but of the previous command.

Yes, in my copy (Part 1 - Physical Layer Simplified Specification v4.10) its in section 4.10.1 (Card Status), table 4-41:

The state of the card when receiving the command. If the command execution causes a state change, it will be visible to the host in the response to the next command. The four bits are interpreted as a binary coded number between 0 and 15.

Regards,
John.

Thanks John. It is present in my Spec too. I just didn't parse it right in my head. So my steps were right except I was reading the states wrong. Now I am able to read the SD card blocks too and tested and works fine.