[En-Nut-Discussion] SD-card problems

[Bernd Walter]

The details are a bit more complex.
I use self build boards based on AT91SAM7X256, AT45DBxx and Micro-SD
header.
The AT45DB is hanging on the same SPI as the SD, so I added some kind
of locks to the Nut/OS code and mine to share the SPI.
I'm using Transcent 1G and 2G card.
Everything worked fine.

I started a new board layout for DIN rail (pictures available on request).
Some components are different - e.g. I use an RTL8201CP PHY instead of
the RTL8201BL, other RS485 transceivers, etc...
The SD header wasn't used with this board so far and I hadn't expected
any kind of problem, since the netlist for this part was the same and
the AT45/db was working as well.
Some days later I finally received a few AT91SAM7X512 and populated a
board with one of them together with SD header.
The AT45DB wasn't working anymore - no answer for get_status.
According to suggestions I've changed by SPI reset to:
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SWRST;
AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
And disabled the reset in spimmc_at91.c because of a new Errata with
this chip.
"41.3.8.7 SPI: Software Reset must be Written Twice"
This is also in rev B X128/X256.
This didn't help, so I analysed everything with the scope and found
excessive 8 bits on line in front of the 0xd7 command byte.
Looked like "41.3.8.3 SPI: SPCK Behavior in Master Mode", although it
is not new for the X512 chip.
In fact my code was always restoring SPI_MR, because of sharing the
SPI with spimmc_at91.c and my own code starts up first, so it always
switched back to default value with AT91C_SPI_MSTR unset.
Initialising with MSTR set was enough to fix.
SPI was working with the AT45DB again, but still not with SD.

I've rechecked the code with old boards and it is still working there.
To double check I populated a new board with an X256 and to my surprise
I saw the same problem, so it seems to be my new board and not the X512.
The X256 is the same charge as on the old board and I use the same SD
card.
But I don't see a obvious problem case with my board.
Power and Ground seems to be stable at every point and a 1µ ceramic is
near the card header.
Traces are shorter than with the old board.

My code:
        SD_fail = 0;
        volid = -1;
#ifdef WITH_SD
        if (NutRegisterDevice(&devAt91SpiMmc0, 0, 0)) {
                SD_fail = 1;
                goto no_sd;
        }
        if (NutRegisterDevice(&devPhat0, 0, 0)) {
                SD_fail = 2;
                goto no_sd;
        }
        // mount partition 1 on MMC0 as PHAT0 FS
        if ((volid = _open("MMC0:1/PHAT0", _O_RDWR | _O_BINARY)) == -1) {
                SD_fail = 3;
                goto no_sd;
        }
no_sd:
#endif

It steps out with SD_fail == 3, which it would do without a card as well.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.