This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SD Card Not Working

Other Parts Discussed in Thread: CC3200, LM3S8962, ENERGIA

With the CC3200 launchpad I'm trying to interface an SD card.  I'm using the sdhost_fatfs example project but no luck so far.  

processors.wiki.ti.com/.../CC32xx_SDHost_FatFS

Everything compiles and loads without issue, but it never sees the SD card.  Within CCS routines always respond as if a card isn't present.  I get the error FR_NOT_READY when I run f_mount().  I am using the following SD card board.  

http://www.gravitech.us/micaad.html

MISO and MOSI are both pulled up with resistors on a bread board.  I'm pretty confident that everything is wired up correctly.  MOSI = PIN_08 (P2.3), MISO = PIN_06 (P2.7), CLK = PIN_07 (P2.6), and SELECT = GND.  Here is a screen shot from the logic analyzer.  D0 = CLK, D1 = MOSI, D2 = MISO.  Some kind of response from the SD card is being generated.  I have tested with 4GB and 2GB microSD cards.

Anybody have any ideas, some trick I'm missing?  I've tried multiple SD cards, multiple SD card breakout boards, and also multiple CC3200 launchpad boards. So I don't think it's an issue with bad hardware.  

Thanks

  • I've figured out some additional things. I'm using a logic analyzer to watch the disk_initialize() routine in diskio.c. The clock signal that I measure on the very first command, CardSendCmd(CMD_GO_IDLE_STATE, 0), is 15MHz. From what I understand it should be 400kHz during initialization, so perhaps this is the source of the error? If so my next question is why is it running so high...?
  • Still not working.  I have verified that there is nothing wrong with the SD card or shield breakout board, and also that my wiring is correct.  I've connected the same breakout board successfully to both a LM3S8962 and MSP430 LP and am able to read from the SD card without issue.  I have also tried with three brand new CC3200 launchpad boards and each exhibits the same behavior, so I can't imagine it being a hardware issue with the CC3200 board either.  I've also tried changing the pin assignments to no avail.  

    Here is readout from a logic analyzer, D0=CLK (P2.6), D1=MOSI (P2.3), D2 = MISO (P2.7).  These results are taken without the SD card/breakout being wired to the board.  I'm just looking at the pins open circuit.  These are the results I get when running the sdhost_fatfs sample project without any modifications.    This result is what I see when the line CardSendCmd(CMD_GO_IDLE_STATE, 0) in diskio.c executes.

    Obviously something is wrong here.  The CLK should be cycling many more times than this.  MISO/MOSI pins also aren't registering as HIGH because their levels are below TTL at 800mV.  Is that correct?  Shouldn't they be above TTL?  

  • Another interesting development. I am able to successfully use the SD card with Energia and the Petit FatFs library. This confirms that my wiring is good and there is nothing wrong with the hardware. Although I think one difference is that energia is relying in the SPI peripheral, whereas the sdhost_fatfs example is utilizing the SD Host peripheral.
  • Bump. I need to communicate with a TI engineer about this.
  • Hi,

    I'm not sure about details of the SD card board you are trying to use, but perhaps the board does not handle all of the signals for SDIO correctly, but does for SPI mode. You may want to either try the board suggested in the example, or use the SPI peripheral.

    -Aaron
  • This is disproved by the fact that I have the SD card working using SPI peripheral instead of the SDHOST peripheral.  From the perspective of the SD card it's the exact same thing - SPI.  The SD card doesn't know anything about the device it's communicating with.  SPI is SPI, and the SD host controller is nothing more than another SPI controller specifically tuned to SD-related commands.  It is not communicating through some other protocol than SPI.  The breakout board doesn't do anything more than make the pins of the SD card available to jumper cables.  When you communicate with an SD card you are communicating DIRECTLY with the SD card, there is no go-between logic IC.  Literally every single SD breakout board works exactly the same way.  You don't even need a breakout board, you could just solder wires directly to the leads on the SD card itself and this would get you the same end-result.

    Bump.  It's been over a week, where are TI engineers?  This is an easily reproducible problem.  I can send you my BIN file (which is actually your BIN file that comes with the SDK).  Someone at TI please help me debug this...?  Of particular interest is the fact that when using the sdhost_fatfs example, the logic levels on the pins for the SD peripheral are at 800mV.  This should be a simple thing for a TI engineer to address.  Is that logic level correct or not?  yes or no?  To my understanding it's not correct but should be 3.3V.  I haven't even connected the SD card/breakout board to the launchpad at this point.  I'm talking about a brand new launchpad taken out of the box, not connected to anything.  All I do is flash the sdhost_fatfs example and place an Agilent 34461A multimeter between GND and the IO pins.  After pin is pulled high level is 800mV.  When running this exact same test with SPI peripheral and pins instead it reads 3.3V.  

  • Did you ever get this figured out? I am having a similar issue, and not getting any response from TI...