SD Card interface with EK-TM4C123GXL using SPI

Hello Nikhil,

Did you check the sd_card example in DK-TM4C123GXL board. It is the same TM4C device on the DK-TM4C123 and if you dig into the fatfs, you will see how the CLK, CS, D0 and D1 are being used between a sd-card and SSI module.

Regards
Amit

Hello Amit,
Thanks for the response.
Yes I have seen those examples but I don't want to implement a file system on sd-card, I just want to read and write raw data to it.
In SSI module there is a signal SSIFss. This is pulled low (in Freescale SPI mode) whenever something is transmitted over Data line.
I just want to know that is there any way through which I can explicitly control the behavior of this pin, say I can force it high whenever I want.

Hello Nikhil,

Correction: SSI does not pull low the SSIFss signal but drives it low. Secondly. If the intention is to do a direct raw data write then why even bother for SSI. You can go ahead and do GPIO bit bang for the interface. It would be simpler, user controlled and have the flexibility of driving any line high and low+ the complexity of debugging the interface as per a SD init sequence when compared to the FATFS.

Regards
Amit

@ Amit,

Bravo for your enforcement of, "clarity of language!"  (Amit, "Correction: SSI does not pull low the SSIFss signal but drives it low."

In a business like ours - where one misplaced semi-colon may wreak havoc - such clarity & precision IS important!

That said - I'm surprised that you've "steered" poster away from the (more normal) "Hybrid mode" of SPI (in which the correct SPI format is selected) - but the SSIFss signal is "liberated" and it alone is placed under user, GPIO Control.  This method (as you assuredly know) enables the SPI peripheral to "automate" all the rest of the SPI signal process - which reduces user time/effort - and usually proves adequate.

Should the Slave SPI device not meet the various SPI formats - supplied by your MCU - only then would a full, "bit-bang" seem (to moi) most appropriate...

Hello cb1,

Having a FS on sd-card and it's init sequence reduces the need for scratch development. The poster insistence on using the module in Hybrid mode with all the nuances of a sd-card would be more troublesome with both the init and hw sequences. Clearly KISS... bit banging will enable easier HW while effort-time-money is spent on sequences.

Regards
Amit

Hi Amit,

Sunday morning - unseasonally warm - midwest US dittos.  (no need to de-ice prior to take-off later today)

I value your comments/ideas - yet we do find the "automation" provided by your (and other ARM vendors) SPI peripherals an effective time/effort saver.

Perhaps the best way - in this case - is to follow your "bit-bang" directive for, "both the init & early hw sequences" - and then revert to the "normal" peripheral generation of SPI signals.  (minus the Fss)

Might I (sneak in) one (hopefully) related point?  Most SD cards available now are "HC."  Speaking specially to our LX4F & TM4C123 (not 129) applications - may our MCUs accommodate these newer, higher capacity SD cards?  And - is there an "upper limit" imposed on the capacity of these SD cards - by either MCU?  I ask as (in the past) these HC cards were not (properly) accommodated by (iirc) your ARM MCUs and those of others...

Perhaps you may wish to contrast this w/the 129 as well - although we have no plans for that MCU class at this time.