Issue of SD Card on Tiva TM4C123GH6PGE

Hi there,

As I checked via System Analyzer/Printf Logs:

The SD card already opened, initialized to SPI mode OK, but got failed when calling SDSPI_diskInitialize() in SDSPITiva.c at command send_cmd:

    /* Initialize the SD Card for SPI mode */
    send_initial_clock_train(hwattrs);

    /* Select the SD Card's chip select */
    takeSPIBus(hwattrs);
    ty = NOCARD;

    /* Send the CMD0 to put the SD Card in "Idle" state */
    if (send_cmd(hwattrs, CMD0, 0) == 1) {     //<=== FAILED HERE
...

send_cmd got failed due to wait_ready got time out, meant that SD card is in busy state, as the following code:

    rxSPI(hwattrs);
    do {
        res = rxSPI(hwattrs);
        if (currentTick != Clock_getTicks()) {
            currentTick = Clock_getTicks();
            tickCount--;
        }
    } while ((res != 0xFF) && (tickCount));

Data from rx fifo could not be read as FF, therefor function send_cmd got timeout as reaching tickCount=500.

Any idea on such issue?

Since sd_card example in StellarisWare use SysTick 10ms timer to handle the time for timer out. Do I need to implement such Timer instead of Clock_getTicks() for more accurate time out?

Thank you,

Tin Phan

Hi,

We have exactly the same problame, only differnce here is that we are using SSI2 on PORT H.

After debugging we get exactly the same results as Tin Phan.

I can complement with oscilloscope measurment.

We have probed CS, MOSI, MISO, CLK  signals.

Only CS signal has moved to 0, other 3 signals have not changed.

Otherwise SSI2 signals are working fine on scope when using simple SPI_open, SPI_transfer functions.

It seems that hardware is workable.

We have no more idea, has anyone else solved already?

Endre Kövér

I doubt timer accuracy on a timeout is a big issue, you could always increase the length of the timeout if you wanted to experiment.

Have you tried a different SD card?  Some vendors are known not to particularly care if the SPI interface works.  As long as it works on popular cameras etc. they are satisfied.  Given the tremendous amount of rebranding even sticking with a given brand may not be sufficient.  You might have more luck with a known manufacturer if that becomes a concern.

If you know the card works in another SPI driven socket that would also eliminate the possibility of a card issue.

Robert

Hi,

Just pulling up pin D0 with 10K resistor could solve such issue.

Remember to add some additional configuration in EKS_LM4F232_initSDSPI(), something like:

    //Added SSI3
    SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI3);

    GPIOPinConfigure(GPIO_PK0_SSI3CLK);
    GPIOPinConfigure(GPIO_PK1_SSI3FSS);
    GPIOPinConfigure(GPIO_PK2_SSI3RX);
    GPIOPinConfigure(GPIO_PK3_SSI3TX);

    GPIOPinTypeSSI(GPIO_PORTK_BASE, GPIO_PIN_0 | GPIO_PIN_1 |
                                    GPIO_PIN_2 | GPIO_PIN_3);


    /* Configure pad settings */
    //SSI_SR.TX can NOT traansmit without this setting

    GPIOPadConfigSet(GPIO_PORTK_BASE,
            GPIO_PIN_0 | GPIO_PIN_3,
            GPIO_STRENGTH_4MA, GPIO_PIN_TYPE_STD);

    GPIOPadConfigSet(GPIO_PORTK_BASE,
            GPIO_PIN_2,
            GPIO_STRENGTH_4MA, GPIO_PIN_TYPE_STD_WPU);

    GPIOPadConfigSet(GPIO_PORTK_BASE,
            GPIO_PIN_1,
            GPIO_STRENGTH_4MA, GPIO_PIN_TYPE_STD);

Good luck!

@ Jack Phan 1,

Our group finds it great that weeks ago you were requesting help - and now you are a, "content provider/helper."  Truly the spirit of the forum - well done.

Not all here realize that the call to GPIOPinTypexxx (xxx = any flavor peripheral) also involves (encapsulates) a further call to, "GPIOPadConfigSet().   And the call to, "PinTypeSSI()" subsequently yields: "GPIOPadConfigSet(ulPort, ucPins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);" which does not fully/properly provide a "known/guaranteed" logic level for any of those peripheral pins which may operate as inputs.  (SSIxRX in this case)

Thus - your use of "GPIOPadConfigSet() - targeting SSIxRX - and including, parameter, "GPIO_PIN_TYPE_STD_WPU" appears well advised.  And - your further "improvement" of that "weak" MCU pull-up via the addition of 10K (external) pull-up insures that the SD card's D0 can meet the MCU's required, logic high level...

Thanks for such a well constructed post...

Hi,

Thank you for very usefull information!

We stepped over the "SD card not working" symptom,

Sorry for late feedback,

BR:

Endre Kover

i am using spi protocol to interface sdhc card.

i have three different cards: sandisk , kingston , sony.

i am successfully interface sandisk , kingston card. but having problem in sony card.

below is link to problem:

http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/322241.aspx

Hi guys,

I just came across this forum post and wanted to let you guys know what the problem is with the timeout (a bad roll-over in the tick count).

http://e2e.ti.com/support/embedded/tirtos/f/355/p/320602/1118831.aspx#1118831