Hi all.
I'm having trouble testing the SD/MMCcard controller core from:
http://opencores.org/project,spimaster

I've attached the top code, I'm using a DE2 board to test this.
Any ideas what am I doing wrong ?

I'm getting no error when I try to initialize the card, but.... although the card is not inserted into his board socket!!!, I've also tried ignore this, an then read some bytes from the card, but i get nothing, except zeroes read.

Anyone please could give me a hand ?
Thanks in advance.

Problem solved, I've it working now.
Cheers.
Alberto.

Problem solved, I've it working now.
Cheers.
Alberto

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

What was it?

John

Hi John.

Due I've not recieved any help in forum, I was doing a google search with the keyword "spimaster".
I found in somewhere a pdf from Lattice that explain more closely all the core function.
(I've attached this now.)
What I missed in the original spimaster specification doccument was that the clk_i clock, should strongly be asyncronous with the spisysclk, so I've done a pll in my DE2 board code, to get a different clock, and I used that one for the clk_i with a -xx phase shift. So now I've a clk_i of 50Mhz with a phase shift of some degrees, and one 50Mhz clk for the spisysclk at zero phase.
That solved my problem of course.

At this time I was able to read the 512 bytes from a sector of the card, and I'm going to do the rest of the code, that includes show video in a VGA monitor from files in the SD, we will see, how many fps I get at the end of this.

This is not my homework, I'm studing by myself, nobody to ask, so it is hard, but I love electronics and it's funny for me.

PS: Sorry for my English.
Cheers.
Alberto.

That sounds a bit yuckie ... why would two clocks need to be 'strongly' asynchronous.
Sounds like a bug in the FIFO to me.
It might be worthwile taking a look at the actual code.

Because, if you simply don't get both clcks async, the core wont work. :)
As I said, that is specified in the "spimaster specification.pdf", but I missed out this before.

PS:And what means "yuckie ..."

Cheers.
Alberto.

That sounds a bit yuckie ... why would two clocks need to be 'strongly' asynchronous.
Sounds like a bug in the FIFO to me.
It might be worthwile taking a look at the actual code.

Because, if you simply don't get both clcks async, the core wont work. :)
As I said, that is specified in the "spimaster specification.pdf", but I missed out this before.

PS:And what means "yuckie ..."

Cheers.
Alberto.
---------------------

Alberto,

Usually it is the other way around. A circuit works when then clocks are in sync but fails if they are async. It does look like there may be a race condition that only seems to work because the async clocks rarely line up at the wrong time.

John

PS yuckie means many things. In this case it means that you cannot explain why it works in one case and fails in the other. Don't be surprised if you see it fail again.

Hi John.
You're right... doing some tests, I discovered that the problem is not an async clk, instead, I found that if I choose the clk_i=50Mhz comming from the DE2 board main clk, and the SpiSysClk=50Mhz comming from the same clk source, the code fails and never get Init the SD card.
So I've tried adding a pll, with two differents clk outs, and I surprissed... that with both clks in phase and a freq=50Mhz each, the code works fine again.
Since I'm very begginer in this, I can't explain why this...but it is working for me now.

Now I've a "new problem"...(althogh not exactly a problem)
First I did a read at some address of the card succesufully... I've checked the data read and it was ok, according the data file in this address of the card, well..
Next i did a loop who reads next addresses of 512 bytes each, and all was going fine..
Next i did a loop where I read forever those data, begining from the first original address, and all was good....BUT.....

The maximun read speed I'm getting is about 128KBps... :(
Since the core say textually (Data transfer at speeds close to SD/MMC card maximum rate.)...I'm very sad about this, because with the SAME card, reading it with a microcontroller I'm getting about 1200KBps... and I supposed to get with this core using SPI card mode, more than 2500KBps

Anyway looking close where is the problem, I found that the card is taking about 4ms to respond that 512 bytes were read. (I do that test measuring some signals in the board with a o'scope, "using some leds outs to look at this too").

Any ideas ?? What am I doing wrong now ?

If you want, I can post my working code again, to take a look at, also, if someone wants to help, I can upload to my website, or where should be, the full Quartus 7.2 project to get download it.

I would like too, if Steve Fielding (who wrote this core), can post in this thread, I think could be some people as me (not so expert in this theme) that wants a good explanation about all this. I don't know if it is correct for this site... or if I'm asking for too much here.... sorry if I'm wrong.

PS: Anyway I've tried with differents SD cards, with similar results. (I never get more than 128KBps read)

Cheers.
Alberto.

Alberto,

I am having difficulties with this core. Right now I am getting an INIT_CMD0_ERROR during initialization. I am using a 50 MHz clock for spiSysClk and a 25 MHz clock for clk_i. This appears to be what both the testbench and the Lattice documentation says will work. I changed the TWO_MS, ONE_HUNDRED_MS and TWO_FIFTY_MS values in spiMasterDefines.v to reflect a 50MHz clock instead of a 48 MHz clock.

I'm not convinced that the problem is not with the SD card or the wiring as I am not getting any activity on the spiDataIn signal. May I have your working code to test board and card and see if I can eliminate these as the source of my problem? My email is "bdon 003 _at_ yahoo _dot_ com".

Thanks,
Brandon

Hi Brandon.
I sent the code by email to you.

Hi.
In this momment I'm in the same place as the last 8 June, no more than 128Kbps with the code. (read above please)
Could someboby help me in this please ?
Thank you in advance.

Some comments/suggestions:

1. 128KBytes/sec... you should be able to do better.

2. What is the SPI clock frequency? Is it 50MHz? 50MHz infers a 6MB/sec transfer rate. Most SD cards can pull this off for both read and write... but not ALL cards can maintain 6MB/sec.

3. What SPI operations are you using for data transfer? Are you using a continuous READ operation?

4. Using a scope probe, are you seeing SELn go high (de-asserted) very often, signaling an interrupted transfer? If so, why?

5. When you see SELn go high, how long is the dead time before the start of the next transfer?

6. Bring the FIFO status flags to an accessible probe point. Are any of the FIFOs consistently empty or full? Use this feedback to narrow down your bottleneck(s).

Good luck!

- Bob

Hi Bob, and thank you so much for your help.

2- The SPI_CLK should be no more than 24Mhz accord to the core specifications, or SD specifications. is that correct ?, In my case I'm using 50Mhz for spisysclk to get a 25Mhz SPI clk, although if I use 100Mhz spisysclk, my SPI clk will be 50Mhz and my card continue working but at 256KBps. (that sounds me strange). The same card tested with a microcontroller doing reads, gives me about 1200KBps, so I trust in this card I'm using to test.

3- The core says that I can, Init SD, write a block or read a block, so I'm reading a block of 512 bytes, and doing a loop to read more blocks, so each time, I send a read block core command to the card, check for no error, and read the data from the buffer, in this case from RX_FIFO_BASE. and so on again.

4- If you mean spiCS_n by SELn, yes, working at 25Mhz SPI clk, I can see every 4.20mSec a short high pulse in spiCS_n. I don't know why, but I supposed that is produced by the core code each time I begin a block read.

5- It is about 20.7uSec

6- I'm checking both FIFO flags for empty or full modifying the original code, and I get always the txfifo empty (I never write to the card), and the rxfifo send me a full state about each 4.2mSec (sounds right, really?).

What I analized in my code is that, all things happends very fast, except when the core recieves the block read command, after that, the core takes the 4.2mSec to respond for "complete" or "ready", after that the data is in the FIFO without error.

Am I clear ? my English is not very good, sorry.
If you want I post my top module here. No problem for me.
Cheers.
Alberto.

So peak transfer rate should be around 3MBytes/sec.

Yes, every block read must be ended with bringing the spiCS_n line high. If you are continually reading from the SD card at 25MHz (SPI clock) rate, 4.2 mS (less 20.7uS dead time) should be long enough to transfer 104,400 bits (13+ KBytes) over the interface. Between spiCS_n pulses, is the SPI clock more or less continually running?

How deep is the rxfifo?

How much time elapses between rxfifo empty flag falling (de-asserted) to rxfifo full flag asserting?

Is the rxfifo being read (drained) while the rxfifo is being filled?

If you have access to the rxfifo counter (how many bytes are in the fifo), trigger your scope on the LSB of this counter. Put a second probe on the SPI clock. Count how many SPI clock cycles occur in one cycle of the fifo counter LSB. If the fifo is 8 bits wide, the number of SPI clocks should be 16 (8 while the fifo counter LSB is low, 8 while the fifo counter LSB is high).

Also: Trigger scope on falling edge of spiCS_n, with a second probe on the rxfifo empty flag. How much time elapses between spiCS_n going low (asserted) and the first byte being shoved into the rxfifo? How many SPI clock pulses in that same period?

- Bob