• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 477 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MMC/SD/SDIO #3 configuration problems

DavidVescovi
Genius 5470 points

I have a problem configuring SDHC controller #3,

I want just a standard 4 bit 1.8 volt SDIO interface. I would like to use gpio 12,13, 17,18,19, and 20 pins which according to the TRM can be used for CLK,CMD, DO,D1,D2 and D3 for MMC #3 if programmed to mode 2.  My pad set up looks like this:

 

 

 

 

 

OUTREG16(&pConfig->CONTROL_PADCONF_ETK_CLK, (INPUT_DISABLE | PULL_INACTIVE | MUX_MODE_2));

/*MMC3_CLK*/

OUTREG16(&pConfig->CONTROL_PADCONF_ETK_CTL, (INPUT_ENABLE | PULL_UP | MUX_MODE_2));

/*MMC3_CMD*/

OUTREG16(&pConfig->CONTROL_PADCONF_ETK_D3, (INPUT_ENABLE | PULL_UP | MUX_MODE_2));

/*MMC3_DAT3*/

OUTREG16(&pConfig->CONTROL_PADCONF_ETK_D4, (INPUT_ENABLE | PULL_UP | MUX_MODE_2));

/*MMC3_DAT0*/

OUTREG16(&pConfig->CONTROL_PADCONF_ETK_D5, (INPUT_ENABLE | PULL_UP | MUX_MODE_2));

/*MMC3_DAT1*/

OUTREG16(&pConfig->CONTROL_PADCONF_ETK_D6, (INPUT_ENABLE | PULL_UP | MUX_MODE_2));

/*MMC3_DAT2*/

My F and I clocks are enabled and I can address the controllers registers ok. The problem is when I probe with scope I can only get the MMC clocks. The data and cmd lines are solid 1.8v.  What is very strange is if I reprogram the CMD pad to be INPUT_DISABLE (i.e. output) I can then see CMD activity synced with clock. but programming D0-3 to outputs does nothing. No matter what I try data lines are never driven.

I know this is not the correct configuration as my SDCH #1 works just fine in 4 bit mode and its pad configuration is as described above (with the exception of being in mode 0).

What is going on?

 

 

 

 

  • 0
    TI__Guru*** 125430 points

    A couple thoughts:

    • Perhaps you need to have INPUT_ENABLE for the clock pin.  I know the SD/MMC interface does a lot of "re-timing" of the clock and not sure if perhaps this needs to be enabled for it to work properly.
    • Do you maybe have the MMC3 pin-muxing configured such that it's connected to 2 different sets of pins?  That is, do you have another set of pins also configured as MMC3 that might be causing contention?  (I'm never tested to see what happens in that particular scenario.)
  • 0 in reply to Brad Griffis
    Genius 5470 points

    Well I have tried everything. I am almost convinced MMC#3 is totally useless. While the internal controller seems to be working I absolutly can not configure the pads to get any kind of output. I do not have the pads double defined. I am always able to get a clock out but CMD and Data lines just are not driven no matter what. I have tried all combonations of pad configs but nothing works. As for the internal loop back clock ..there is no bit defined for MMC#3.  There is for MMC#2 and MMC#1 (even though I think MMCSDIO1ADPCLKISEL in CONTROL_DEVCONF0 does absolutly nothing). I can understand the need for MMCSDIO2ADPCLKISEL in CONTROL_DEVCONF1 as SDHC #2 can be set up for external txeiver .. which would need (optionally) a clk out and in.   If MMC #1 does not have a clk in what is the use of  MMCSDIO1ADPCLKISEL?

    And what about MMC#3 .. it does not have and clock loopback bit defined?

    I tried all these configurations on both our board (3503) and the EVM with the same results.

    There seems to be a lack of documentation on just how to make MMC #3 actually work.

  • 0 in reply to DavidVescovi
    TI__Guru*** 125430 points

    Which package are you using (CBB, CBC, or CUS)?

  • 0 in reply to Brad Griffis
    Genius 5470 points

    I am thinking the problem might indeed be with our peripheral. The way I understand the spec there should be no activity on the data lines untill the commands are responded too.

    After scoping and counting clocks it looks like our peripheral is not responding to initial commands... which don't involve the data lines at all. Is this correct understanding?

  • 0 in reply to DavidVescovi
    Genius 5470 points

    Wea re using CUS package.

  • 0 in reply to DavidVescovi
    TI__Guru*** 125430 points

    DavidVescovi said:

    I am thinking the problem might indeed be with our peripheral. The way I understand the spec there should be no activity on the data lines untill the commands are responded too.

    After scoping and counting clocks it looks like our peripheral is not responding to initial commands... which don't involve the data lines at all. Is this correct understanding?

    Card initialization and commands are all done using the CMD signal.  You would not see anything on the DAT signals until actual data was being transferred.