SPI / SD Card communication issues
A year has passed since the question was asked, but I decided to add to it because I was having similar issues embedding SD-card driver into FPGA. I agree with commenters to your question that you need to give information about what was happening before the failed SPI cycle, and what happens after.

Generally, while there's SD specification for the SD-cards, it is slightly puzzled and made me spend not one hour understanding what is wrong with my design.

So, let's start...


Initialization: there's prerequisite to have spare clock cycles with CS deactivated to make card initialize itself and understand that there's host out there. It will also get an idea which type of SPI is used.
Command cycle start: you will need spare clock cycles before you assert CS low to start the command, and ideally several clock cycles after you assert CS low and start putting command onto MOSI line. Several here means n*8. Those spare cycles are required to ensure card recovers from previous I/O cycle if there was a problem it in (e.g you application did not transfer whole data/status, and card still expects that host will read/send this data or status). Sparely clocking with CS high will convince card that previous operation should be cancelled.


When I made these two above properly, I did not get invalid response codes from SD-card any more. There're some other peculiarities handling SD-cards through SPI, but they should be dealt when needed, because command cycle itself, then response and data phase are relatively well explained in specification, and you will probably not have issue implementing it.