mmc_spi and flash cards

mmc_spi and flash cards

[Cliff Brake]

Hello,

I'm debugging some issues with mmc_spi.  I have 3 mini-SD cards:

- transcend 2G - works
- Sandisk 2GB ultra - works if we play games with the CPHA bit, but
then the transcend card breaks.
- ATP Pro - does not get very far: mmc1: error -38 whilst initialising SD card

Thinking it might be a problem with the PXA270 SPI driver/hardware, I
switched to using the gpio_spi driver, and got exactly the same
results.  I have verified the power is stable.  Next, I plan to dig
into the driver and protocol, but wondered how its working for others:

- has 2.6.31 mmc_spi has been tested with a number of flash cards and works?
- I noticed the driver is playing games with the SPI mode to keep CS
high during some clock pulses.  Is there any concern that the CS will
glitch while changing modes?
- any suggestions as to what to look for?

Thanks,
Cliff

Re: mmc_spi and flash cards

[Cliff Brake]

Some more decoding of response codes.  Its interesting the both cards
return an error at the same place in the init sequence.  I suspect
that we are sending something bogus to the cards, but the transcend
and ATP cards seems to recover, but the Sandisk does not.

It appears that all this activity happens before the card is mounted
(must be scanning partition tables, etc).


=====================================================
Sandisk:

mmc0: starting CMD18 arg 7927f000 flags 000000b5
mmc0:     blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0:     CMD12 arg 00000000 flags 0000049d
mmc_spi spi1.0:   mmc_spi: CMD18, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:   mmc_spi: CMD12, resp R1B
mmc_spi spi1.0:   ... CMD12 response SPI_R1B: resp 0008 00000000

>> STOP_TRANSMISSION
>> bit 3 -> R1_SPI_COM_CRC (the CRC of the last command failed)

mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
mmc0:     4096 bytes transferred: 0
mmc0:     (CMD12): -84: 00000008 00000000 00000000 00000000

>> -84 (matches code, EILSEQ)

mmcblk0: retrying using single block read
mmc0: starting CMD17 arg 7927f000 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:   ... CMD17 response SPI_R1: resp 0004 00000000

>> R1_SPI_ILLEGAL_COMMAND

mmc0: req done (CMD17): -38: 00000004 00000000 00000000 00000000
mmc0:     0 bytes transferred: 0
mmc0: starting CMD13 arg 00000000 flags 00000195
mmc_spi spi1.0:   mmc_spi: CMD13, resp R2/R5
mmc_spi spi1.0:   ... CMD13 response SPI_R2/R5: resp ff04 00000000

>> another R1_SPI_ILLEGAL_COMMAND

mmc0: req done (CMD13): -38: 0000ff04 00000000 00000000 00000000
mmcblk0: error -38 sending status comand
mmcblk0: error -38 sending read/write command, response 0x4, card status 0xff04
end_request: I/O error, dev mmcblk0, sector 3970040
mmc0: starting CMD17 arg 7927f200 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:   ... CMD17 response SPI_R1: resp 0004 00000000
mmc0: req done (CMD17): -38: 00000004 00000000 00000000 00000000


==================================================================
Transcend card:

mmc0: starting CMD18 arg 77eff000 flags 000000b5
mmc0:     blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0:     CMD12 arg 00000000 flags 0000049d
mmc_spi spi1.0:   mmc_spi: CMD18, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:   mmc_spi: CMD12, resp R1B
mmc_spi spi1.0:   ... CMD12 response SPI_R1B: resp 0040 00000000

>> bit 6, R1_SPI_PARAMETER (commands argument, block length) was out of allowed range for this card.

mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
mmc0:     4096 bytes transferred: 0
mmc0:     (CMD12): -14: 00000040 00000000 00000000 00000000
mmcblk0: retrying using single block read
mmc0: starting CMD17 arg 77eff000 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:   ... CMD17 response SPI_R1: resp 0040 00000000
mmc0: req done (CMD17): -14: 00000040 00000000 00000000 00000000
mmc0:     0 bytes transferred: 0
mmc0: starting CMD13 arg 00000000 flags 00000195
mmc_spi spi1.0:   mmc_spi: CMD13, resp R2/R5
mmc_spi spi1.0:   ... CMD13 response SPI_R2/R5: resp ff4c 00000000
mmc0: req done (CMD13): -14: 0000ff4c 00000000 00000000 00000000
mmcblk0: error -14 sending status comand
mmcblk0: error -14 sending read/write command, response 0x40, card status 0xff4c
end_request: I/O error, dev mmcblk0, sector 3930104


================================================================
ATP card

mmc0: starting CMD18 arg 3d07f000 flags 000000b5
mmc0:     blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0:     CMD12 arg 00000000 flags 0000049d
mmc_spi spi1.0:   mmc_spi: CMD18, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc_spi spi1.0:   mmc_spi: CMD12, resp R1B
mmc_spi spi1.0:   ... CMD12 response SPI_R1B: resp 0040 00000000

>> bit 6, R1_SPI_PARAMETER (commands argument, block length) was out of allowed range for this card.

mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
mmc0:     4096 bytes transferred: 0
mmc0:     (CMD12): -14: 00000040 00000000 00000000 00000000
mmcblk0: retrying using single block read
mmc0: starting CMD17 arg 3d07f000 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc0: req done (CMD17): 0: 00000000 00000000 00000000 00000000
mmc0:     512 bytes transferred: 0
mmc0: starting CMD17 arg 3d07f200 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc0: req done (CMD17): 0: 00000000 00000000 00000000 00000000
mmc0:     512 bytes transferred: 0
mmc0: starting CMD17 arg 3d07f400 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc0: req done (CMD17): 0: 00000000 00000000 00000000 00000000
mmc0:     512 bytes transferred: 0
mmc0: starting CMD17 arg 3d07f600 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc0: req done (CMD17): 0: 00000000 00000000 00000000 00000000
mmc0:     512 bytes transferred: 0
mmc0: starting CMD17 arg 3d07f800 flags 000000b5
mmc0:     blksz 512 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmc_spi spi1.0:   mmc_spi: CMD17, resp R1
mmc_spi spi1.0:     mmc_spi: read block, 512 bytes
mmc0: req done (CMD17): 0: 00000000 00000000 00000000 00000000
mmc0:     512 bytes transferred: 0
mmc0: starting CMD17 arg 3d07fa00 flags 000000b5


On Wed, Nov 18, 2009 at 10:57 AM, Cliff Brake <cliff.brake@gmail.com> wrote:
> Hello,
>
> I'm debugging some issues with mmc_spi.  I have 3 mini-SD cards:
>
> - transcend 2G - works
> - Sandisk 2GB ultra - works if we play games with the CPHA bit, but
> then the transcend card breaks.
> - ATP Pro - does not get very far: mmc1: error -38 whilst initialising SD card
>
> Thinking it might be a problem with the PXA270 SPI driver/hardware, I
> switched to using the gpio_spi driver, and got exactly the same
> results.  I have verified the power is stable.  Next, I plan to dig
> into the driver and protocol, but wondered how its working for others:
>
> - has 2.6.31 mmc_spi has been tested with a number of flash cards and works?
> - I noticed the driver is playing games with the SPI mode to keep CS
> high during some clock pulses.  Is there any concern that the CS will
> glitch while changing modes?
> - any suggestions as to what to look for?
>
> Thanks,
> Cliff
>

Re: mmc_spi and flash cards

[Matt Fleming]

On Mon, 28 Dec 2009 12:58:28 -0500, Cliff Brake <cliff.brake@gmail.com> wrote:
> 
> >> STOP_TRANSMISSION
> >> bit 3 -> R1_SPI_COM_CRC (the CRC of the last command failed)
> 
> mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
> mmc0:     4096 bytes transferred: 0
> mmc0:     (CMD12): -84: 00000008 00000000 00000000 00000000
> 

That's weird.

> mmc_spi spi1.0:   mmc_spi: CMD12, resp R1B
> mmc_spi spi1.0:   ... CMD12 response SPI_R1B: resp 0040 00000000
> 
> >> bit 6, R1_SPI_PARAMETER (commands argument, block length) was out of allowed range for this card.
> 

And that just seems completely bogus; the STOP_TRANSMISSION command
doesn't require any parameters.

Having read mmc_spi_response_get() I'm wondering if it's actually trying
to interpret a busy signal as a response code. Would you mind giving
this patch a go and seeing if the BUG_ON() triggers?

diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index d55fe4f..3e36ff4 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -310,6 +310,7 @@ static int mmc_spi_response_get(struct mmc_spi_host *host,
 
 checkstatus:
 	bitshift = 0;
+	BUG_ON(*cp == 0xff);
 	if (*cp & 0x80)	{
 		/* Houston, we have an ugly card with a bit-shifted response */
 		rotator = *cp++ << 8;

Re: mmc_spi and flash cards

[Cliff Brake]

On Sat, Jan 2, 2010 at 9:17 AM, Matt Fleming <matt@console-pimps.org> wrote:
> On Mon, 28 Dec 2009 12:58:28 -0500, Cliff Brake <cliff.brake@gmail.com> wrote:
>>
>> >> STOP_TRANSMISSION
>> >> bit 3 -> R1_SPI_COM_CRC (the CRC of the last command failed)
>>
>> mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
>> mmc0:     4096 bytes transferred: 0
>> mmc0:     (CMD12): -84: 00000008 00000000 00000000 00000000
>>
>
> That's weird.
>
>> mmc_spi spi1.0:   mmc_spi: CMD12, resp R1B
>> mmc_spi spi1.0:   ... CMD12 response SPI_R1B: resp 0040 00000000
>>
>> >> bit 6, R1_SPI_PARAMETER (commands argument, block length) was out of allowed range for this card.
>>
>
> And that just seems completely bogus; the STOP_TRANSMISSION command
> doesn't require any parameters.
>
> Having read mmc_spi_response_get() I'm wondering if it's actually trying
> to interpret a busy signal as a response code. Would you mind giving
> this patch a go and seeing if the BUG_ON() triggers?
>
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index d55fe4f..3e36ff4 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -310,6 +310,7 @@ static int mmc_spi_response_get(struct mmc_spi_host *host,
>
>  checkstatus:
>        bitshift = 0;
> +       BUG_ON(*cp == 0xff);
>        if (*cp & 0x80) {
>                /* Houston, we have an ugly card with a bit-shifted response */
>                rotator = *cp++ << 8;
>

Matt,

I applied the above patch, and the BUG_ON did not trigger.  Appreciate
the ideas, and welcome any other thoughts.

I wonder if there is something wrong with the previous
READ_MULTIPLE_BLOCK command, and that is what the cards are
complaining about, not the STOP_TRANSMISSION command?

I'm decoding the READ_MULTIPLE_BLOCK arguments next ....

Thanks,
Cliff

Re: mmc_spi and flash cards

[Matt Fleming]

On Thu, 14 Jan 2010 16:09:05 -0500, Cliff Brake <cliff.brake@gmail.com> wrote:
> 
> I wonder if there is something wrong with the previous
> READ_MULTIPLE_BLOCK command, and that is what the cards are
> complaining about, not the STOP_TRANSMISSION command?
> 

If there was some wrong with the READ_MULTIPLE_BLOCK command the card
should have complained before the host started reading data.

> I'm decoding the READ_MULTIPLE_BLOCK arguments next ....
> 

Your best bet is probably going to be getting a 'scope on the bus.