This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]