I am trying to record data from a few SPI sensors to a SD card. I can do each of these functions independently but when I try to combine them, it doesn't work out. I am using the ATMEL supplied example as the method of recording to the SD card which means that I have to reconfigure the SPI_MR.

For the SPI sensors I have it configured as:
AT91C_BASE_SPI->SPI_MR = AT91C_SPI_MSTR | AT91C_SPI_PS_VARIABLE | AT91C_SPI_MODFDIS;

and for the SD card it needs to be:
// Configure SPI in Master Mode with No CS selected !!!
pSpiHw->SPI_MR = AT91C_SPI_MSTR | AT91C_SPI_MODFDIS | AT91C_SPI_PCS;
then:
spiMr = pSpiHw->SPI_MR;
spiMr |= AT91C_SPI_PCS;
spiMr &= ~((1 << cs) << 16);
pSpiHw->SPI_MR = spiMr;

I initialize the SD card just fine and do a quick write/read test fine, then I reconfigure for the SPI sensor and get through that ok, but when I reconfigure to write to the SD card, I get a "SD card did not answer the command error"

What am I missing in the reconfiguration?

I would like to minimize the amount of editing I need to do to the example provided.

Thanks

>>What am I missing in the reconfiguration?

Probably, for one, that you always want AT91C_SPI_PCS applied to the SPI_MR register when you deselect the SD card, so the chip select bit isn't flapping around randomly.

If you have more than one chip select active (low) much chaos will ensue.

If you don't like how the SPI controller handles the CS pins, you can do what Linux does, and just assert/dis-assert them as regular GPIO pins.

Stick a logic analyzer or scope on the chip select pins, and SPI pins.

Thanks for the reply. Checking with the scope was a good idea, I did and didn't find any issues with the SD cs flopping when I was requesting data from the SPI sensor. I did add code to make sure AT91C_SPI_PCS was set as well and still had an issue. I also in the mean time switched the MR to be fixed and set the CS in there for the SPI sensor to see if that would help, but it didn't. It instead gave me a SDSPI driver error instead.
It does seem to be only when I read/write to the SPI sensors that the SD card misbehaves because if I comment out only that section, SD is fine.
Is there any way a SD card can get confused by seeing the SPI clock even if the CS is not active (high)?

Sorry, I should say: I checked the CSs with a scope and found no issues. Thought that might be confusing;)

Ok folks, for those interested, I think that I found the problem. It seems that the write function provided by ATMEL lacks the ability to determine that it must send a stop transaction token. The read does however have this which is why I didn't have a problem with the write/read test at the beginning of my program. In the end, it wasn't the fact I was reading SPI sensors...

Now, I am a bit of a hack at this so if any of you out there know a bit more about SPI mode for SD cards and find my approach incorrect, PLEASE let me know. Thanks.