[SOLVED] SD Card Hardware Interfacing Issue

[umairmukati]

Hi, everyone,
I have learnt alot about SD card interfacing and i am able to save and extract data from an SD card(in simulation).
After several attempts I am also able to run it in hardware environment, but my issue is just not simple because although it runs on hardware now, it detects SD card sometimes while does not detect SD card sometime, even it is also detecting while no SD card is attached minorly :/.
Can any one help me solving this strange and "ghostia" issue? (Keeping in mind, that I am able to run it in simulation successfully but not in Hardware)

Best Regards,
and My best Wishes to my problem solver ,

Umair Mukati.

 

[captainshahid]

i think there is interfacing and spi clock timing issue.

post your circuit image.

 

[doraemon]

Hello!

it detects SD card sometimes while does not detect SD card sometime, even it is also detecting
while no SD card is attached minorly :/.

It depends how you try to detect it. Is it by the SD card socket switch (if any)? Is it by software?
- If you have unpredictable result with the switch method, I would check if there is a pull-up or
pull-down on that switch.
- If you try to initialize it and get a wrong result, then there can be zillions for reasons.

Dora.

 

[umairmukati]

The Circuit is just meant for hardware...., also I have tried at all of the spi clock prescalars, even increased the no. of retries to detect it.


---------- Post added at 18:19 ---------- Previous post was at 18:10 ----------

It depends how you try to detect it. Is it by the SD card socket switch (if any)? Is it by software?
- If you have unpredictable result with the switch method, I would check if there is a pull-up or
pull-down on that switch.
Dora.

Hi Dora,

I am able to detect and even write it using proteus and further I have verified it.
I am using a SD card jack to connect a microSD through headers.

Hello!

- If you try to initialize it and get a wrong result, then there can be zillions for reasons.

Dora.

It is detecting that I am using SD card (a non SDHC version).
I am able to detect it successfully above 50%.
I have also increased the no. of retries so that it can receive a valid response but the same problem persists.

By the way, I really appreciate your reply.
Regards

 

[FvM]

Why don't you use a known working level translation circuit?

 

[umairmukati]

Why don't you use a known working level translation circuit?

Hi,
I have used various know level translator circuit but what I am using now give me the better result over them.
Regards:smile:

 

[FvM]

I would consist on:
- 5 to 3.3V voltage divider or driver ICs instead of shorting the outputs of a 5V provessor with a 3.3V Z-diode
- 3.3 to 5V level translator for DO
- pullup resistors for unconnected SD card signal pins
- in case your software has difficulties to distinguish a floating DO signal from a reasonable card output, a pullup on DO as well
- a 3.3V supply for the card with sufficient bypassing. As it's not shown in schematic, we can only guess about the point. Supplying the card from a 741 output would be "not so good", I assume

Nevertheless, the problems may be software related as well.

 

[umairmukati]

FvM,
Kindly tell which values I should use to get a 2:3 so that I does not limit the speed of SPI communication?

 

[FvM]

I mostly used 74LVC gates as level converter, (inputs can be overdriven to 5V), but an 1.2k to 2.4k voltage divider performed well in a test. ATmega SPI speed is limited to moderate 8 MHz anyway.

 

[umairmukati]

Thanks,
Can you please tell me that what is a better circuit for the implementation of 3.3v to 5v translation?
Regards.

 

[FvM]

According to specification, the ATmega input voltage range (Vih >= 0.6 Vcc) is still compatible with 3.3 V logic output, but with a very low margin. I prefer 74HCT gates (TTL input level specification) as 3.3 to 5V CMOS level translater.

 

[umairmukati]

Hi FvM,
The problem remains the same.
I think the card I am testing in simulation is an image file of MMC, but the card I am testing in hardware is an SD Card, I have triple checked all of my connection and they are giving outputs as wished.
I am sending you my edited program which is able to interface with all three cards (i.e. MMC, SD, SDHC).
Best Regards
Umair.

 

[FvM]

I'm not sure about your available tools, my method to check the software would be to run it in a hardware debugger and check the response of each command against expected results. Apart from the point that this is a lengthy process (just design craftmanship), I can't do it because I don't have the required hardware.

I've been also asking about the card supply voltage. Can we be sure that it doesn't bring up the issues?

 

[umairmukati]

I am now cent % sure that it is not an issue of hardware, but of my software. The software is detecting MMC but I can't simulate an SD card on proteus and the main issue is in the code for SD version.
As I know, there are three different approaches to detect memory cards.
Can you please provide me the code for SD card version 1 or SD card version 2 so I can verify the my whole code?

BTW, Thanks for the replies.

 

[FvM]

I'm using Microchips MDD File System in a project. It's supporting PIC18.

 

[umairmukati]

FvM,
One last thing I want to ask you that I am able to read write only after I finished my controller programming, It also works when I do not power off just reset the controller, but after powering it off. After applying power again the card is again undetected. During this power off and on, I hadn't changed any settings.
BTW, I am using AVR ISP programmer to program it through SPI protocol.
Regards.

 

[mtwieg]

Wait, you're simulating an SD card? It's not as if SD cards have very consistent behavior between different manufacturers and grades. Plus there's SD 1.1, SD 2.0, SDHC, MMC, etc...

Are you doing your initialization routine at 400KHz or less? Are you sending the required >74 clock cycles before initializing? How are you actually determining if a card is detected? Normally you would do this by actually reading a few registers off of it, and I don't think there's any way to get false positives if there's no actual SD card attached, unless there are just huge bugs in your software.

Could you just post your initialization/detection code?

 

[umairmukati]

Could you just post your initialization/detection code?

Hi, here is my code:

unsigned char SD_init(void)
{
	unsigned char i=0, response=0;
	unsigned int retry=0;
	spi_init();
	
	usart_puts("\n\r1");
	
	_delay_ms(2);
	
	CS_DEASSERT;
		
	/*First 74 Clocks*/
	for(i=0;i<40;i++)
		SPI_rec();
	
	/*Software Reset*/
	CS_ASSERT;
	for(retry=0;response != 0x01;++retry)
	{
		response = SD_sendCommand(GO_IDLE_STATE, 0); //send 'reset & go idle' command
		if(retry > 0xfe){
			CS_DEASSERT;
			//usart_puts("\r\nCard not detected!");
   			return 1;   //time out, card not detected
		}
	}
	usart_puts("\r\nCard detected!");
	retry = 0;
	/**/
	if(retry == 0){
		do
		{
			response = SD_sendCommand(SD_SEND_OP_COND, 0); //activate card's initialization process
			//response = SD_sendCommand(SD_SEND_OP_COND, 0); //same command sent again for compatibility with some cards
			retry++;
			if(retry>0xfe){retry = 0; break;} //time out
		}while(response);
	}
	
	if(retry == 0){
		do
		{
			response = SD_sendCommand(SEND_OP_COND, 0); //activate card's initialization process
			//response = SD_sendCommand(SEND_OP_COND, 0); //same command sent again for compatibility with some cards
			retry++;
			if(retry>0xfe){usart_puts("MMC");return 1;} //time out
		}while(response);
	}
	SD_sendCommand(CRC_ON_OFF, OFF); //disable CRC; deafault - CRC disabled in SPI mode
	SD_sendCommand(SET_BLOCK_LEN, 512); //set block size to 512
	CS_DEASSERT;
	
	usart_puts("\r\nDetected\r\n");
	SPI_HIGH_SPEED;
	return 0; //successful return
}

And here is the SPI initialization code

void spi_init(void)
{
	PORTB |= 1<<CS;
	DDRB = (1<<4)|(1<<5)|(1<<7);
	SPCR = 0x52; //setup spi: master mode, msb first, sck phase low, sck idle low
	SPSR = 0x00;
}

 

[umairmukati]

Atlast, got it working now, the problem was with the command sending function.
Thanks FvM, for your great help.