[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #16 from Mike Jones <mjones@linear.com> ---
Now I have the micro SD custom board with a Beagle and the offending Samsung
card which is now known to not get in the idle state.

The init 40 00 00 00 00 95 is sent and the reply includes:

FF C0 7F, and the reply in the code is getting the 0x7F.

       // The card should reply with 0x01. FF suggests that there is
        // no card. Any other response indicates some synchronization
        // problem. For example the card might still be responding to
        // some request from a previous session which aborted at an
        // inconvenient moment. Some dummy traffic is generated in the
        // hope that this gets things back in sync.
        if (0x01 != reply) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

Execution gets to the cog_spi_transfer. The assumption in the code is lack of
0xFF means there is a card, but there is trouble. The Beagle reports a log of
clocks with 0xFF.

The code loops back around and gets the same response to the init.

My understanding is CMD0 returns an R1 response with the bits meaning:

B0 Idle State 
B1 Erase Reset
B2 Illegal Command 
B3 Com CRC Error 
B4 Erase Seq Error 
B5 Address Error 
B6 Parameter Error
B7 0

C0 seems an unlikely real value because bit 7 is not zero. 7F indicates all
errors and idle state.

As an experiment:

        if (0x01 != (reply & 0x01)) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

I changed the top line and added "& 0x01" to ignore the other error bits. Made
the same change a few lines below after the loop.

Now the code passes through to the version command 48 00 00 01 AA 87 and it
returns C1 7F. The code sees the 7F as the reply. The code assumes this is a V1
card that does not understand CMD8. But it also did not really seem to
understand the reset.

By continuing on it is clear the card returns 7F for every command.

I put in a working 2GMB SanDisk so I can compare its behavior.

It is interesting that the version command returns in the Beagle view 01 00 00
01 AA FF, but it places the second 01 at response[2]. This same card when
plugged into the larger SD carrier on the Tower board put that at response[3].
Therefore, it is clear that the Tower card, the one with V1 silicon, has the
same data, but shifted in the code.

Back to the Samsung card.

I slow down the clock to 1Mhz. Same result.

I tried to turn of double baud rate, but get a compile error in
spi_freescale_dspi.c line 194 

Description    Resource    Path    Location    Type
‘CYGHWR_DEVS_FREESCALEDSPI_DSPI_CTAR1_AUX_USE_DBR’ undeclared here (not in a
function)    Sidekick2-4        line 194, external location:
/opt/ecos/ecos-3.0/packages/devs/spi/freescale/dspi/current/src/spi_freescale_dspi.c
   C/C++ Problem

So that was a dead end.

Changed Normal chip select delay to 0. No difference.

As a final test, I plug the Samsung card into linux and it works.

I might have time for a short experiment before my trip. Near term, getting the
2GB card to work on the Tower is of higher value to me than fixing the Samsung
card. I will have more time in early May, but I am out of ideas other than
looking at the timing of the MOSI to make sure it is aligned with the SCLK.
However, running at 1Mhz should have eliminated that as a possibility. I also
verified with the Beagle that the bus ran slower. But did not verify this on
the scope.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From ecos-bugs-return-10218-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Apr 18 21:16:42 2013
Return-Path: <ecos-bugs-return-10218-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 7620 invoked by alias); 18 Apr 2013 21:16:42 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 7581 invoked by uid 89); 18 Apr 2013 21:16:41 -0000
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 21:16:40 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id A15DC4680016; Thu, 18 Apr 2013 22:16:38 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001764] Enhancement of MMC/SD over SPI driver
Date: Thu, 18 Apr 2013 21:16:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Disk
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: mjones@linear.com
X-Bugzilla-Status: NEEDINFO
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001764-777-qMdoEFX9lJ@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00249.txt.bz2
Content-length: 4094

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #16 from Mike Jones <mjones@linear.com> ---
Now I have the micro SD custom board with a Beagle and the offending Samsung
card which is now known to not get in the idle state.

The init 40 00 00 00 00 95 is sent and the reply includes:

FF C0 7F, and the reply in the code is getting the 0x7F.

       // The card should reply with 0x01. FF suggests that there is
        // no card. Any other response indicates some synchronization
        // problem. For example the card might still be responding to
        // some request from a previous session which aborted at an
        // inconvenient moment. Some dummy traffic is generated in the
        // hope that this gets things back in sync.
        if (0x01 != reply) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

Execution gets to the cog_spi_transfer. The assumption in the code is lack of
0xFF means there is a card, but there is trouble. The Beagle reports a log of
clocks with 0xFF.

The code loops back around and gets the same response to the init.

My understanding is CMD0 returns an R1 response with the bits meaning:

B0 Idle State 
B1 Erase Reset
B2 Illegal Command 
B3 Com CRC Error 
B4 Erase Seq Error 
B5 Address Error 
B6 Parameter Error
B7 0

C0 seems an unlikely real value because bit 7 is not zero. 7F indicates all
errors and idle state.

As an experiment:

        if (0x01 != (reply & 0x01)) {
            DEBUG1("%s(): loop %d, card did not enter idle state, code %02x\n",
                __FUNCTION__, i, reply);
            if (0x0ff != reply) {
                cyg_spi_transfer(dev, cyg_mmc_spi_polled, 128, mmc_spi_ff_data,
(cyg_uint8*) 0);
            }
        }

I changed the top line and added "& 0x01" to ignore the other error bits. Made
the same change a few lines below after the loop.

Now the code passes through to the version command 48 00 00 01 AA 87 and it
returns C1 7F. The code sees the 7F as the reply. The code assumes this is a V1
card that does not understand CMD8. But it also did not really seem to
understand the reset.

By continuing on it is clear the card returns 7F for every command.

I put in a working 2GMB SanDisk so I can compare its behavior.

It is interesting that the version command returns in the Beagle view 01 00 00
01 AA FF, but it places the second 01 at response[2]. This same card when
plugged into the larger SD carrier on the Tower board put that at response[3].
Therefore, it is clear that the Tower card, the one with V1 silicon, has the
same data, but shifted in the code.

Back to the Samsung card.

I slow down the clock to 1Mhz. Same result.

I tried to turn of double baud rate, but get a compile error in
spi_freescale_dspi.c line 194 

Description    Resource    Path    Location    Type
‘CYGHWR_DEVS_FREESCALEDSPI_DSPI_CTAR1_AUX_USE_DBR’ undeclared here (not in a
function)    Sidekick2-4        line 194, external location:
/opt/ecos/ecos-3.0/packages/devs/spi/freescale/dspi/current/src/spi_freescale_dspi.c
   C/C++ Problem

So that was a dead end.

Changed Normal chip select delay to 0. No difference.

As a final test, I plug the Samsung card into linux and it works.

I might have time for a short experiment before my trip. Near term, getting the
2GB card to work on the Tower is of higher value to me than fixing the Samsung
card. I will have more time in early May, but I am out of ideas other than
looking at the timing of the MOSI to make sure it is aligned with the SCLK.
However, running at 1Mhz should have eliminated that as a possibility. I also
verified with the Beagle that the bus ran slower. But did not verify this on
the scope.

-- 
You are receiving this mail because:
You are the assignee for the bug.
>From ecos-bugs-return-10220-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Apr 19 16:17:27 2013
Return-Path: <ecos-bugs-return-10220-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-ecos-bugs@sources.redhat.com
Received: (qmail 7708 invoked by alias); 19 Apr 2013 16:17:27 -0000
Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: ecos-bugs-owner@sourceware.org
Delivered-To: mailing list ecos-bugs@sourceware.org
Received: (qmail 7674 invoked by uid 89); 19 Apr 2013 16:17:27 -0000
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197)
    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 19 Apr 2013 16:17:25 +0000
Received: by mail.ecoscentric.com (Postfix, from userid 48)
	id D30134680007; Fri, 19 Apr 2013 17:17:23 +0100 (BST)
X-Original-To: unassigned@bugs.ecos.sourceware.org
Delivered-To: unassigned@bugs.ecos.sourceware.org
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: unassigned@bugs.ecos.sourceware.org
Subject: [Bug 1001764] Enhancement of MMC/SD over SPI driver
Date: Fri, 19 Apr 2013 16:17:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: eCos
X-Bugzilla-Component: Disk
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: mjones@linear.com
X-Bugzilla-Status: NEEDINFO
X-Bugzilla-Priority: low
X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-1001764-777-q7f2rhIGW2@http.bugs.ecos.sourceware.org/>
In-Reply-To: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001764-777@http.bugs.ecos.sourceware.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://bugs.ecos.sourceware.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013/txt/msg00251.txt.bz2
Content-length: 414

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id\x1001764

--- Comment #17 from Mike Jones <mjones@linear.com> ---
At Ilija's suggestion I tried changing Tick-only drops CS. The Samsung card
does not work with this with either setting, and the SanDisk card works with
both settings.

--
You are receiving this mail because:
You are the assignee for the bug.