xesscorp / vhdl_lib Goto Github PK

I'm trying to implement the SD card controller with a Cyclone IV E and I'm having trouble understanding the initializing part. You wrote:

[..]. The busy_o output will be high during the 
initialization and will go low once it is done. 

After the initialization command sequence, the SD card will send back an R1
response byte. If only the IDLE bit of the R1 response is set, then the 
controller will repeatedly re-try the ACMD41 command while busy_o remains 
high. 

If any other bit of the R1 response is set, then an error occurred. The 
controller will stall, lower busy_o, and output the R1 response code on the
error_o bus. You'll have to pulse reset_i to unfreeze the controller. 
If the R1 response is all zeroes (i.e., no errors occurred during the 
initialization), then the controller will lower busy_o and wait for a 
read or write operation from the host. The controller will only accept new
operations when busy_o is low.

What exactly is the R1 response? I think I understood the 2 other parts regarding the read and write but I'm missing the initialization part..

Thanks for any help.

On SDHC cards, the SD Card controller (SDCard.vhd) stalls in line 455:

https://github.com/xesscorp/VHDL_Lib/blob/master/SDCard.vhd#L455

What seems to happen is: SDHC cards seem to take longer to be ready for reading, so they seem not to only send one NO_TOKEN_C, but many. But as far as I got it (sorry if I am wrong, I am a beginner): Don't we need to continue sending something like 0xFF to be able to do some kind of "active waiting" (otherwise SPI won't send anything back)?

If yes, is there any easy way to do so without redoing the whole state machine? Something like replacing the "null;" command by something like this:

txCmd_v := x"FFFFFFFFFFFF";
bitCnt_v := 8; -- only send one byte, not the whole txCmd_v, as we only want to "poll"
getCmdResponse_v := true;
rtnState_v := RD_BLK; -- return when done sending the dummy command
state_v  := START_TX

The goal would be to keep the SDHC card "actively engaged", so that we finally are able to receive a START_TOKEN_C.

What I am referring to, when writing "actively engaged" or "active waiting" is also what is written here:

http://electronics.stackexchange.com/questions/13112/sd-card-read-write-problems-in-spi-mode

In SPI, you have to send data to be able to read from the client. Remember that the master always drives the clock line. The dummy data I send when reading SD cards is 0xFF, too.

When ALLOW_ROLLOVER_G => false,
I can't get the rotary encoder value over 50% even if turning the thing like a bloke
I'm investigating why, haven't found the reason for this yet.

Scenario: 8 bit register, shared with a Xess RotaryEncoderWithCounter module..

signal accumulator_s : std_logic_vector(7 downto 0);
...
port map (
clk_i => clk_fast,
duty_i => accumulator_s,

...
u1 : RotaryEncoderWithCounter
generic map (ALLOW_ROLLOVER_G => false, INITIAL_CNT_G => 0)
port map (
clk_i => clk_i,
a_i => rotEncA_i,
b_i => rotEncB_i,
cnt_o => accumulator_s

Looking deeper into this...

The DualPort module sometimes forwards the SdramCntl's done signal to the wrong port. This happens if pipelining is enabled and there is a write command on one port, followed immediately by a port switch and a command on the other port.

This is illustrated in the following signal trace: done1_o gets asserted in response to a write request on port 0, because in the DualPort module's eyes, the port switch has already occured at that point.

I don't know if there's a better solution, but I think I solved the problem by having DualPort generate the signals “from scrach” instead of forwarding them: 9562c33