hi mountainhua,

i have run the code at around 20Mhz, may be u can try by running the code at 10-15MHz.

cheers

Hi all,

I found that the signal ack_o_s is never set in SD_bd.v if you are using RAM_MEM_WIDTH_32. For me this made all the command stuff work (with tweaks to the software side of things), but I couldn't get and data to transfer.

Hope this helps,

Jon Pry

I've been fighting with this core for a few days now. While it seems to be a lot of non random code, I have to wonder if anyone has ever got it working. From some of the early posts in this thread, I get the impression they have, but I don't see how. I've found several errors so far.

First of all, there is a documentation problem. It turns out that after you set the software reset register to zero, you have to wait at least 64 sd clock cycles before doing anything. Prior to this, there is some sort of terrible feedback in the state machines that is only stopped by some counter that seems to do nothing but count down from 64.

Second of all, the normal int status register that the sd_wait_rsp() code relies on is broken. After sending a request, there is a glitch where the register shows no command is in progress, but really it is just getting started. I believe the author is at least vaguely aware of this problem, and it is the cause of much trouble with initialization.

Looking at the sd_controller.c file in cvs, it becomes apparent that writes to the command and arg register are often reversed. This has the effect of inserting wait states at certain key times, depending on the speed of your code/processor, and since most of the argument values are zero, this somehow tends to work.

This is easily fixed though. In SD_Cmd_serial_host.v, there are a couple instances like

STATUS[3:0] = 16'b0000_0000_0000_0001;


getting rid of the [3:0] prevents the normal int status from temporarily indicating done.

Also, I'm using the sd-model.v to do simulations. There is a problem there where it says:

if(startUppCnt == 'TIME_BUSY).

startUppCnt is never initialized, so the comparison is always false. Barring that, the vector isn't wide enough to be equal to 64 which is the default value of TIME_BUSY. Many potential fixes there.

At this point I am only trying to receive a block of data, I haven't even though about transmitting it. I've actually gotten 4 bytes from the card, assuming I disable CRC checks. Part of me believes it is actually a timing issue. But it still behaves strangely in the simulations, so I am tempted to figure out the behavioral side of things before dealing with the timing.

For a while I couldn't get the data master to issue the read command. This statement in sd_controller_top.v is at least related to it:

assign cmd_busy = int_busy | status_reg[0];

Trouble is that int_busy is always high. I think it is only there to indicate that the processor is executing commands. Assuming that the processor isn't dumb enough to issue a DMA request and then try to issue commands, I think it is not necessary. So I changed it to:

assign cmd_busy = status_reg[0];

This got the transfer to take place, but it is off by like 48 bytes, and crc fails for good reason.

I suspect there are more problems with transmit, as synthesis seems to trim out the transmit BD fifo.


Regards,

Jon