SD Card Controller

I developed a basic SD card controller in SPI mode.
At first, i struggled for a while, trying to figure out why
sometimes it worked and sometimes not.

1) The card connetor is "flying" for now (breadboard)
and 2) i used a "one hand long" cable to connect it to
the FPGA module.

I guess the problem is about reflections and card
sensitivity to slow rising and falling signal edges.

When i 1) shortened the cable and, at the same time,
2) lowered the spi clock frequency (below 400Khz)
it started working on every test.

** Is there any way i can rise the spi clock while
keeping the sd connector "off board"? **




I also notice that (with consecutive single block writes)
as the sector number i write to sequentially, increases,
more time is required for the block operation to complete.

** Is it normal? **

Starting from  sector 1, i've not reached the sector 1000.
I had to increase a timeout reference.

-- 

>
>** Is there any way i can rise the spi clock while
>keeping the sd connector "off board"? **
>

Try terminating the signals appropriately. For instance, series
terminations on the CS, SCK and MOSI lines at the master.

And before you ask, the value depends on the characteristic impedance of
the cable...

"RCIngham" <robert.ingham@gmail.com> ha scritto nel messaggio 
news:GemdnXcN7tHaHxXVRVn_vwA@giganews.com...
> >
>>** Is there any way i can rise the spi clock while
>>keeping the sd connector "off board"? **
>>
>
> Try terminating the signals appropriately. For instance, series
> terminations on the CS, SCK and MOSI lines at the master.
>
> And before you ask, the value depends on the characteristic impedance of
> the cable...
>

Before deciding to go on with a lower clock, i tried a parallel
termination. I tried a single resistor close to the receiver's SCK
line. It didn't help. Now reading again something about Digital
Signal Integrity i noticed that if the parallel resistor is not really
close to the receiver it cannot work because there ia a part of
impedance left unmatched. Series termination should not pose
this issue, so i hope they would do. Anyway i remember i read
somewhere that the highest termination value is about 330 ohm,
as a rule of thumb... perhaps. I think it's not possible though, to
calculate the real impedance, since the signal path is broken into:
fpga board, cable, breadboard, the small sd card board.

>
>"RCIngham" <robert.ingham@gmail.com> ha scritto nel messaggio 
>news:GemdnXcN7tHaHxXVRVn_vwA@giganews.com...
>> >
>>>** Is there any way i can rise the spi clock while
>>>keeping the sd connector "off board"? **
>>>
>>
>> Try terminating the signals appropriately. For instance, series
>> terminations on the CS, SCK and MOSI lines at the master.
>>
>> And before you ask, the value depends on the characteristic impedance
of
>> the cable...
>>
>
>Before deciding to go on with a lower clock, i tried a parallel
>termination. I tried a single resistor close to the receiver's SCK
>line. It didn't help. Now reading again something about Digital
>Signal Integrity i noticed that if the parallel resistor is not really
>close to the receiver it cannot work because there ia a part of
>impedance left unmatched. Series termination should not pose
>this issue, so i hope they would do. Anyway i remember i read
>somewhere that the highest termination value is about 330 ohm,
>as a rule of thumb... perhaps. I think it's not possible though, to
>calculate the real impedance, since the signal path is broken into:
>fpga board, cable, breadboard, the small sd card board.
>

Have you measured the signals with an oscilloscope? What are the the rise
and fall times, especially of SCK? Perhaps the drive capability of the
outputs of the FPGA is insufficient relative to the high capacitance of the
load? More drive AND series termination?

"RCIngham" <robert.ingham@gmail.com> ha scritto nel messaggio 
news:x_2dnY2PK44pHhTVRVn_vwA@giganews.com...
> >
>>"RCIngham" <robert.ingham@gmail.com> ha scritto nel messaggio
>>news:GemdnXcN7tHaHxXVRVn_vwA@giganews.com...
>>> >
>>>>** Is there any way i can rise the spi clock while
>>>>keeping the sd connector "off board"? **
>>>>
>>>
>>> Try terminating the signals appropriately. For instance, series
>>> terminations on the CS, SCK and MOSI lines at the master.
>>>
>>> And before you ask, the value depends on the characteristic impedance
> of
>>> the cable...
>>>
>>
>>Before deciding to go on with a lower clock, i tried a parallel
>>termination. I tried a single resistor close to the receiver's SCK
>>line. It didn't help. Now reading again something about Digital
>>Signal Integrity i noticed that if the parallel resistor is not really
>>close to the receiver it cannot work because there ia a part of
>>impedance left unmatched. Series termination should not pose
>>this issue, so i hope they would do. Anyway i remember i read
>>somewhere that the highest termination value is about 330 ohm,
>>as a rule of thumb... perhaps. I think it's not possible though, to
>>calculate the real impedance, since the signal path is broken into:
>>fpga board, cable, breadboard, the small sd card board.
>>
>
> Have you measured the signals with an oscilloscope? What are the the rise
> and fall times, especially of SCK? Perhaps the drive capability of the
> outputs of the FPGA is insufficient relative to the high capacitance of 
> the
> load? More drive AND series termination?
>
>

I don't have an oscilloscope available because i'm not into that
every day, but if i am not able to make it work with series
terminations i think i'll get one. In any case i'm a bit concerned
about using an oscilloscope... if fast signal transitions occurs, as
this article explains:

http://www.interfacebus.com/Design_Termination.html

the frequencies involved are "far" above the nominal one.

Here's the formula they show:

Signal Freq [GHz]=[0.35]/[Signal Transition Time{nSec)].

and perhaps a basic oscilloscope won't see that. This also
seems to be confirmed in this recent post:

"Micro-SD card  initialisation-problem"

at comp.arch.embedded.

I guess something wrong with the clock was going on because
when the reading of the CSD/CID registers failed it was because
i got 0xFC as the "start" token while expecting 0xFE.
(0xFC == 0xFE << 1 ??).  Reading the 16 data bytes anyway,
i got corrupted data.

I'll blindly try a set of series termination first. Starting from 10
ohm  up to 120/220 ohm. I don't have them with me now...
i was unprepared for this sort of issue.


BTW... SD cards have an Erase command. In every implementation
i saw (mostly microcontroller based) it is never used. I can write
to the same sector again and again correctly. So when is Erase
used on SD Cards?

-- 

Here's a shot in the dark:

Are you certain the clock edge is where you want it relative to the data 
setup and hold time requirements?

"John_H" <newsgroup@johnhandwork.com> ha scritto nel messaggio 
news:MM6dnaCHurSKUhTVnZ2dnUVZ_oPinZ2d@comcast.com...
> Here's a shot in the dark:
>
> Are you certain the clock edge is where you want it relative to the data 
> setup and hold time requirements?

The spi driver runs concurrently with the card controller
logic, in its own state machine. So it has the chance to
drive clock and data with the right phase according to
cpol = 0, cpha = 0. Simulation shows a 90 degree
phase shift between sck and mosi.

>
>"John_H" <newsgroup@johnhandwork.com> ha scritto nel messaggio 
>news:MM6dnaCHurSKUhTVnZ2dnUVZ_oPinZ2d@comcast.com...
>> Here's a shot in the dark:
>>
>> Are you certain the clock edge is where you want it relative to the
data 
>> setup and hold time requirements?
>
>The spi driver runs concurrently with the card controller
>logic, in its own state machine. So it has the chance to
>drive clock and data with the right phase according to
>cpol = 0, cpha = 0. Simulation shows a 90 degree
>phase shift between sck and mosi.
>

That is probably not optimal. For *most* SPI interfaces, you want SCK
rising edge in the middle of the MOSI and MISO periods.

UNLESS you have a data sheet that shows otherwise, of course, as there is
no such thing as "standard SPI"!

"RCIngham" <robert.ingham@gmail.com> ha scritto nel messaggio 
news:5omdnbYYqdJYBRDVRVn_vwA@giganews.com...
> >
>>"John_H" <newsgroup@johnhandwork.com> ha scritto nel messaggio
>>news:MM6dnaCHurSKUhTVnZ2dnUVZ_oPinZ2d@comcast.com...
>>> Here's a shot in the dark:
>>>
>>> Are you certain the clock edge is where you want it relative to the
> data
>>> setup and hold time requirements?
>>
>>The spi driver runs concurrently with the card controller
>>logic, in its own state machine. So it has the chance to
>>drive clock and data with the right phase according to
>>cpol = 0, cpha = 0. Simulation shows a 90 degrees
>>phase shift between sck and mosi.
>>
>
> That is probably not optimal. For *most* SPI interfaces, you want SCK
> rising edge in the middle of the MOSI and MISO periods.
>

That's what i meant. The clock rises in the middle of MOSI  "bit pulse".
Anyway since i'm still fixing a bug in the application part of  the project,
i've just run a simulation again and i actually see that  MOSI changes on
every falling edge of SCK. When SCK rises MOSI is stable.

Considering the 0xFE/0xFC mismatch as i said before and the
corrupted data i got as well,. it seems wierd to me that on every
test that failed, i ALWAYS  got 0xFC followed by the SAME
corrupted data. I'm not sure whether reflections and friends
would alter data in different ways on every run. Just a thought.

"devices" <me@home> ha scritto nel messaggio 
news:4888e604$0$1083$4fafbaef@reader2.news.tin.it...
>
> "RCIngham" <robert.ingham@gmail.com> ha scritto nel messaggio 
> news:GemdnXcN7tHaHxXVRVn_vwA@giganews.com...
>> >
>>>** Is there any way i can rise the spi clock while
>>>keeping the sd connector "off board"? **
>>>
>>
>> Try terminating the signals appropriately. For instance, series
>> terminations on the CS, SCK and MOSI lines at the master.
>>
>> And before you ask, the value depends on the characteristic impedance of
>> the cable...
>>
>
> Before deciding to go on with a lower clock, i tried a parallel
> termination. I tried a single resistor close to the receiver's SCK
> line. It didn't help. Now reading again something about Digital
> Signal Integrity i noticed that if the parallel resistor is not really
> close to the receiver it cannot work because there ia a part of
> impedance left unmatched. Series termination should not pose
> this issue, so i hope they would do. Anyway i remember i read
> somewhere that the highest termination value is about 330 ohm,
> as a rule of thumb... perhaps. I think it's not possible though, to
> calculate the real impedance, since the signal path is broken into:
> fpga board, cable, breadboard, the small sd card board.
>

After fixing a couple of bugs, i've finally replaced the short cable
with four terminating resistors.

10 ohm killed the... iusse. I haven't checked data values yet
but it never timed out at any speed. Usually when it doesn't
time out data is ok.

--