Micro SD Card, SPI to SD Mode

Thread Starter

kamiqash

Joined Jan 2, 2012
5
Hello,

Has any one worked or written a SD Card on SD Mode while their micro controller was sending data on SPI mode. Any ideas of how to achieve this goal would be highly appreciated.
Secondly is this conversion possible through a FPGA.
Thankyou

Kamiqash
 

thatoneguy

Joined Feb 19, 2009
6,359
There are libraries for SD card communication for PIC and AVR, I'm not sure what you need/have for FPGA.

Which FPGA design system are you using? You may want to just start by reading the SD card specifications, which include timing and commands, and go from there.
 

Thread Starter

kamiqash

Joined Jan 2, 2012
5
Hello thatoneguy,

Yes I have already read the timing, pinouts and commands of the SD card. But frankly speaking timing is all that I have which I can work with. My basic question remain the same, do you know any one who has worked on the conversion of SD card's SPI mode to SD card's SD mode.
My scenario is, I have a microcontroller at one end sending data in SPI mode, to increase some performance, it is advised to use SD card in SD mode. So I need some tips how to change between two modes.
One more thing, do you think it can be done without writing the whole protocol in FPGA, by just using the timing diagram???

Thankx
kamiqash
 

davebee

Joined Oct 22, 2008
540
To my knowledge, SD cards power up in SD mode, and once switched to SPI mode, there is no programatic way to switch them back to SD mode. They would have to be restarted. I don't know whether that would entail a full power-down or whether just a software reset would be enough. But if you want to use SD mode then that detail is irelevant, since the cards power up in SD mode.

If you want better performance, I guess you want 4 bit parallel mode. What's difficult about that is that while the trailing CRC is optional in SPI mode, it is required in SD mode. (two different CRCs: CRC7 for commands and CRC16 for data.) Not only that, but in 4 bit mode, the data CRC has to be generated for each of the 4 bits separately.

It's not rocket science, it's just a lot of well-defined bit manipulation, so as long as you follow the specification, it should be doeable by either a microcontroller or by FPGA, but it is quite a bit more complicated than using SPI mode.
 

Thread Starter

kamiqash

Joined Jan 2, 2012
5
Hello,

Yes I understand the fact that when the card is switched to SPI mode, we can not go back to SD mode , but here's the thing, the card is not going to be switched in SPI mode. FPGA will make sure of that. To be very basic, starting of with the Master Microcontroller sends commands in SPI mode, FPGA receives the Commands, converts them to Parallel SD mode (somehow???), the card receives the data in SD mode.

It is said simply but to do this I need sequence of bits to make decisions.
Assuming what Controller is sending, and trusting the bit patterns, I have simulated all the Read, Write and Multiple write for SD mode.
Problem
The problem comes when hardware does not behave as it is supposed to. Immediate problem is FPGA never takes in a condition:
if Chip_Select is <low>, then synchronize master and slave clocks.
It somehow doesn't recognize Chip_Select signal. So no clock synchronization means no guarantee that data coming out of parallel ports in correct.

I hope the problem definition and what I am trying to do is a little more clear, because up till now we are talking about either SPI mode or SD mode. My situation is SPI (Controller) --> FPGA --> SD Mode (Card).

Thnx

Kamiqash
 

kubeek

Joined Sep 20, 2005
5,794
To be very basic, starting of with the Master Microcontroller sends commands in SPI mode, FPGA receives the Commands, converts them to Parallel SD mode (somehow???), the card receives the data in SD mode.
I don´t see any reason to do it like that.
Should the uC be only capable of SPI mode, do you think that going SD on the card side will speed anything up?

The SPI on the uC side can only move one bit at a time, and I am quite sure the SPI clock speed of the uC is lower than the max speed of the card. Thus even if you nicely shift 4bits at a time out of the card into your converter, you will still be limited by the SPI speed and will gain nothing.

Or is there anything you didn´t mention that makes this approach feasible? Also, what exact uC are we talking about? Is it preprogrammed or can you change the programming?
 

Thread Starter

kamiqash

Joined Jan 2, 2012
5
Hello Kubeek,

The microcontroller used in this project in Sentio 32, It is based on AVR's 256UC3B Microprocessor. The programming in microcontroller can be changed. The file system used for writing the card in FAT32.

When writing the card on SPI interface we face a 150ms delay in writing.

Writing: The Master (Microcontroller) sends packets of data(512 Bytes) to the Slave( SD Card). After end of each Packet it waits for <data-response>. This means the data is received without error. Now the Slave (SD Card) will be programmed. As long as it is being programmed it sends busy tokens. The problem lies here. This busy stream sometimes can be as long as 150 ms . This is long enough to lose data

For this it was recommended that we try SD mode instead of SPI mode.
So the conversion dilemma kicks in. Hoping you'd have some idea about how to proceed.

Thnx
Kamiqash
 

kubeek

Joined Sep 20, 2005
5,794
Hello Kubeek,

The microcontroller used in this project in Sentio 32, It is based on AVR's 256UC3B Microprocessor. The programming in microcontroller can be changed. The file system used for writing the card in FAT32.

When writing the card on SPI interface we face a 150ms delay in writing.

Writing: The Master (Microcontroller) sends packets of data(512 Bytes) to the Slave( SD Card). After end of each Packet it waits for <data-response>. This means the data is received without error. Now the Slave (SD Card) will be programmed. As long as it is being programmed it sends busy tokens. The problem lies here. This busy stream sometimes can be as long as 150 ms . This is long enough to lose data

For this it was recommended that we try SD mode instead of SPI mode.
So the conversion dilemma kicks in. Hoping you'd have some idea about how to proceed.

Thnx
Kamiqash
First, the 150ms delay is AFAIK inherent to the FLASH writing cycle inside the card, and should be same in both SPI and SD mode. It´s been a while since I last worked with SD cards, but I don´t see any other reason that could create such a delay that would be present in SPI and theoreticaly wouldn´t be present in the SD mode.

Second, why convert SPI to SD protocol using another costly and complex chip, when you can simply implement the SD protocol in the uC?

I don´t have the state diagrams of SPI and SD modes infront of me, but implementing a state machine that would convert between them seems like a nightmare to me.
 

Thread Starter

kamiqash

Joined Jan 2, 2012
5
Very nicely summed up Kubeek, it is a nightmare, but the uC used in this project is custom made by some one else. As it is told to me, we do not have enough pins to run it on SD mode, thus no other choice but to convert SPI to SD mode.
As far as the SPI protocol is, I have read its a subset of SD protocol. Which means any command SPI sends to card in SD mode, the card will respond back through bidirectional command pin. Is this so????

Thnx
kamiqash
 

kubeek

Joined Sep 20, 2005
5,794
Sorry, I am busy with exams so I don´t have time to look it up. Try downloading the exact protocol specifications both for the spi(mmc) mode and the sd 1-bit and 4-bit modes and you should see what needs to be done.

You could (more like should!) set up a different uC, implement all the three protocols and and see if you can actually get the writes any faster with the same card on a perfect system before you start with converting the protocols. Still much less man-hours than possibly pointlessly creating the actual conversion.
 
Top