James Newton, Host wrote:
>> 1. Send 80 clocks with /CS inactive (high)
> 
> Check, although the SD spec says with /CS low, I've tried it both ways.

CS high puts the card into MMC mode when it boots. The CMD0 with CS low pushes 
it into SPI mode.

>> 2. Make /CS active (low), transmit a CMD0 command -- note 
>> that the card is in 
>> MMC mode with CRCs enabled, so send the sequence 
>> 40,00,00,00,00,95 [hex]
> 
> Check. I can see it on the scope. Clocking data on the positive clock
> transition.

Actually, my code clocks on the falling edge IIRC...

The code I'm using is (in pseudo-BASIC code):
   MMC_SHIFTOUT = data_to_send
   MMC_SHIFTIN = 0

   FOR MMC_LOOP = 8 DOWNTO 0 DO
     MMC_CLOCK = low			// clock low
     delay_us(8)				// settling delay, 8us
     MMC_SHIFTIN = MMC_SHIFTIN shl 1	// shift data in
     IF MMC_MISO == high THEN MMC_SHIFTIN = MMC_SHIFTIN or 1
					// shift data in
     delay_us(8)				// settling delay
     MMC_MOSI = (MMC_SHIFTOUT and 0x80)	// shift data out
     delay_us(8)				// settling delay
     MMC_CLOCK = high			// clock high
     delay_us(8)				// settling delay
   NEXT MMC_LOOP

   MMC_MOSI = high			// make MOSI idle
   RETURN MMC_SHIFTIN			// return MMC_SHIFTIN


>> 3. Now the card is in SPI mode. Wait for an R1 response from the card.
> 
> Ok, now what exactly does that mean? As I read the spec and the sample
> programs, after that CMD0 string is finished, you have to clock out one full
> byte (8 clocks) and then another byte, where the last clock should get a
> high from the card. E.g. it should return  0x00, 0x01 after the CMD0.

An R1 response is a single byte, defined as:

MSBit             LSBit
     7 6 5 4 3 2 1 0

7: Always zero
6: Parameter error
5: Address error
4: Erase sequence error
3: Comms. CRC error
2: Illegal command
1: Erase reset
0: In idle state

You keep reading out bytes until you get the response code 0x00 (all OK, card 
not in IDLE state, i.e. active).

> I wish I could get you a screen shot but his old unit doesn't do that except
> via an HPIB printer which I don't have. I am sending EXACTLY the right
> sequence. 

HP 1630 or 1650 series by any chance?
I wrote a program that takes a capture of the printing sequence and converts 
it into a BMP file.

> The only thing I can think of is that I need to send CMD0 more than once or
> that I need to keep clocking until it grabs the SDO line. 

How are you sending the SET_OP_COND (CMD1) command?
It should be sent as six bytes: 41,00,00,00,00,FF [hex], and you need to send 
it repeatedly until you get a valid response byte (0x00 or 0x01).

My WAIT_RESPONSE function clocks out a byte, checks to see if it is 0x00 or 
0x01, and if it isn't it goes back and clocks out another byte. When the card 
returns 0x00 or 0x01, it returns the value and exits.

It sends CMD0, waits for a response, then sends CMD1 and waits. I'm also 
waiting 250ms for the contacts to settle after the card-in switch (actually a 
pin on the MMC slot that's grounded by the card) goes to the 'card is in the 
slot' state.

It might be worth trying to do more initialisation clock cycles before sending 
the CMD0 -- my code appears to be doing 160 bits (20x 0xFF bytes).

Thanks.
-- 
Phil.                         |  (\_/)  This is Bunny. Copy and paste Bunny
piclist@philpem.me.uk         | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/     | (")_(") world domination.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist