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.

Apparent problem with MMC2 port on AM3517

Other Parts Discussed in Thread: AM3517

All:

One of our board houses has hit a problem with the MMC2 port on AM3517 that cannot resolve. More details are below:

We are almost ready to launch AM3517 module but encounter a serious bug that we cannot even get working on the Logic demoboard and therefore want to check with TI if our demoboard is broken or that this is a known AM3517 bug.

The description of problem is as follow which already be sent to your TI Taiwan FAE but without response. (maybe he is just waiting for US response but we will value some initial feedback in order to avoid a large delay on our developmentcycle).

***quote engineer***

We got a problem on am3517 about mmc2 port, we tried to use the mmc2 port but without success,
    the mmc2 can output cmd/clk signal but all sdcard/sdio-card has no response at all, no data output from data-pins. (the same routine on mmc1 is working fine)
   
      both kernel and u-boot cannot working.

***end quote engineer***

As you can see above we have issues with the MMC2 port not only on our board but also on the Logic EVM board and want to verify if on the original EVM's this is working or not. If it's working. Can you be so kind to send us the U-Boot and kernel that is used on the board in order for our engineers to verify operation on our side.

As a final note. Our schematics is straight 100% copy from the EVM on this part. No modifications there. On the MMC2 we have connected a WIFI module (TI chips made by JOR-JIN a TI customer as well and introduced to us by TI Taiwan).

Thank you in advance so much for your help.

Kind regards,

Marcel vandenHeuvel
TechNexion Ltd.
17F-1, No. 16, Jian Ba Road
Chung Ho City, 235, Taipei, Taiwan
phone  : +886-2-82273585
mobile : +886-988 112650
fax    : +886-2-82273590
email  : marcel@technexion.com

  • Nick:

    Our AM3517 EVM has an expansion board that provides SD Card slots for MMC2 and MMC3.  The SOM module

    on the AM3517EVM has a Wifi interface device, that shares the MMC2 bus.  If the MMC2 bus is used to boot,

    the Wifi device needs to be disabled in U-BOOT code. 

    Please let me know which PSP software version you are working with.

    Do you require boot from MMC2, followed by setup to use Wifi after boot up?

    Regards,

    Michael T

  • I have been trying to boot from MMC2 on the Logic board, but I can't get it to work either.  It doesn't get to U-Boot so I doubt the problem is with U-Boot.  I have tried switches 1, 2, and 4 set to ON-ON-ON and ON-ON-OFF, but I have not had any luck.  We are trying to boot from MMC2 on our own custom control and I'm seeing the same thing.

    Any help would be appreciated.
    Thank you.

    David Peters

     

  • There seems to be 2 topics in this thread. 

    The original question from Nick doesn't mention booting, it looks like there are having a fundamental problem of communicating with MMC2.  There is BSL code available from the Logic PD website which has test code for the WLAN/Bluetooth module.  This should give you some clues on configuring MMC2 for communication with that module.

    Regarding David question, MMC2 boot on AM3517 requires the use of an external transceiver.  This is because the module is expecting MMC clock to be input on MMC2_CLKIN signal, and also to accomodate the dual voltage MMC cards (could be 1.8V or 3.3V).   The AM3517 EVM was never really intended to boot from MMC2, as there is no transceiver between AM3517 and MMC2, however, i think it could possibly work, because the transceiver that serves the WiFi module could be used to get the clock, and you would need to setup the AM3517 I/Os to 3.3V for 3.3V cards.  I don't know if MMC2 boot is supported in the current PSP release.

    regards,

    James

  • Hi,

            I have the same problem, even with the BSL code in CCS. According with the refrence manual, the SD bus voltage and the votage support on MMC2 must be set 1.8v only,  that meaning it can not support 3.3v SD card directly?

         By the way ,  in BSL code when initialize the MMC1 it config a register 0x80002520, I can not find any information about this register in the reference.Where I can search for that information? 

  • zhenhong:

    I downloaded the BSL code from LogicPD, but I did not find any reference to a register at 0x80002520. 

    Could you clarify which file contained this code?

    Regards,

    Michael T

  • Michael:

    It's the file bsl\src\evmam35xx_mmcsd.c, these codes are:

             CLRBIT_REGL(CONTROL_PBIAS_LITE, PBIASLITEPWRDNZ0);
             SETBIT_REGL(CONTROL_PBIAS_LITE, PBIASLITEVMODE0);

    the CONTROL_PBIAS_LITE is defined 0x800002520.

  • CONTROL_PBIAS_LITE is only applicable to MMC1.  It's used for selecting between 1.8V and 3.0V operation.  MMC2 is 1.8V only and does not have a corresponding register.

    I found the following note in the TRM:

    The BIAS voltage must be set using the procedure described in ,
    Extended-Drain I/Os and PBIAS Cell Basic Programming Guide.

    I don't see that guide anywhere.  In your case I don't think it's applicable but I'll see about getting it published for people that have questions related to MMC1.

    EDIT 15 Sept 2010:  I'm told the PBIAS logic was removed entirely on AM35xx so my statement above is not applicable.  It would apply only to OMAP35x and AM37x.

  • We till have this problem on AM3517.

    and I have some questions:

    1. Why you say MMC2 is 1.8V only?  The MMC2's vot level is by VDDSHV(1.8V or 3.3V) setup, we tried this.

    2. Why when we to access MMC1 and the MMC2 has signals too? even MMC2 has no connected anything.

    our kernel is from PSP-03.00.01.06.

  • Hardy Weng said:
    1. Why you say MMC2 is 1.8V only?  The MMC2's vot level is by VDDSHV(1.8V or 3.3V) setup, we tried this.

    Sorry, you're right.  I forgot that AM3517 allows you to use 1.8/3.3V I/O.

    Hardy Weng said:
    2. Why when we to access MMC1 and the MMC2 have signals too? even MMC2 has no connected anything.

    Sorry, I don't understand this question.

    Here's a key thing for MMC2:

    If you're not using any kind of external transceiver you must make sure you set CONTROL_DEVCONF1[MMCSDIO2ADPCLKISEL] = 1.

  •  

    thanks, it's working.

    please apply this patch into kernel, thanks.

     

    diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
    index 18ad931..b584b1c 100644
    --- a/arch/arm/mach-omap2/devices.c
    +++ b/arch/arm/mach-omap2/devices.c
    @@ -655,6 +655,10 @@ static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
                                    omap_mux_init_signal("sdmmc2_dat7.sdmmc2_dat7",
                                            OMAP_PIN_INPUT_PULLUP);
                            }
    +
    +                       if (mmc_controller->slots[0].internal_clock)
    +                               omap_ctrl_writel(omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1)|OMAP2_MMCSDIO2ADPCLKISEL, OMAP343X_CONTROL_DEVCONF1);
    +
                    }

                    /*

     


  • I have also the same MMC2 issue on AM3517.
    The interface MMC2 which using sdcard/sdio at boot and kernel can't work, but MMC1 does work functional.
    MMC2 is using through MMC slot on Application_Board. So about the h/w part, is there any configurations I need to set up for MMC2 ?
    The BSP version I am using now is AM35x-OMAP35x-PSP-SDK-03.00.00.05_patch_WiLink6
    How could I solve this problem?
    Another thing, is wireless module on SOM going through mmc2 ? Is there any influence on using MMC2 slot ?


    Hi Hardy

    The content of device.c you modified is not the same with my code.

    am3517_wilink/build/linux-03.00.00.05/arch/arm/mach-omap2/devices.c
    static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
                            int controller_nr)
                           
                                     
    if (mmc_controller->slots[0].internal_clock) {
                            u32 v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
                            v |= (1 << 24);
                            omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
                    }



    Thank you.

  • nathan kuo said:


    I have also the same MMC2 issue on AM3517.
    The interface MMC2 which using sdcard/sdio at boot and kernel can't work, but MMC1 does work functional.
    MMC2 is using through MMC slot on Application_Board. So about the h/w part, is there any configurations I need to set up for MMC2 ?
    The BSP version I am using now is AM35x-OMAP35x-PSP-SDK-03.00.00.05_patch_WiLink6
    How could I solve this problem?
    Another thing, is wireless module on SOM going through mmc2 ? Is there any influence on using MMC2 slot ?


    Hi Hardy

    The content of device.c you modified is not the same with my code.

    am3517_wilink/build/linux-03.00.00.05/arch/arm/mach-omap2/devices.c
    static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
                            int controller_nr)
                           
                                     
    if (mmc_controller->slots[0].internal_clock) {
                            u32 v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
                            v |= (1 << 24);
                            omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
                    }



    Thank you.

     

    I saw that in "if (cpu_is_omap2420() ..." section, but not in "if (cpu_is_omap34xx())" ,

    so I added one for omap34xx.

     

  • Hardy:

    The following wiki article discusses hardware considerations for AM3517 MMC ports:

    http://processors.wiki.ti.com/index.php/SD-MMC_Usage_Notes_on_AM35x

    MMC2 boot is not directly supported by the AM3517EVM since an external

    MMC2 tranceiver is required to supply MMC2_CLKIN, but this could be done

    with a custom board.

    I will look into support for MMC2 boot in the PSP software.

    The WiFi device on the SOM shares the MMC2 interface.  To use MMC2

    on the expansion board, MMC2_DAT4:7 must not be set as GPIO inputs.

    Regards,

    Michael T

    PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

  • Hardy:

    Correction to my last sentence: "MMC2_DAT4:7 must be set as GPIO inputs"

    Regards,

    Michael T

    PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

     

  • Michael T said:

    Hardy:

    Correction to my last sentence: "MMC2_DAT4:7 must be set as GPIO inputs"

    Regards,

    Michael T

    PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

     

     

    I know "MMC2_DATA4:7" need to be set as GPIO, but the "MMC2_DATA:7" has no affect,

    the clockin is still functional and will mix MMC1 signals together, (this means when I using MMC1 I can get signals from MMC2's pin,but those pins has no connected)

    so "CONTROL_DEVCONF1[MMCSDIO2ADPCLKISEL] = 1" still need. that's strange.

     

  • Hardy:

    CONTROL_DEVCONF1[MMCSDIO2ADPCLKISEL] = 1 is correct to select internal loopback of the clock for MMC2.

    Signalling on MMC2 without an SD Card is probably due to pin muxing and GPIO setup.  To clarify, the following pinmux

    selections are needed:

    In U-Boot code: 

    /board/ti/am3517evm/am3517evm.h

    MUX_VAL(CONTROL_PADCONF_MMC2_DAT4, (IEN | PTD | DIS | M4 )) /* gpio_136 */\
    MUX_VAL(CONTROL_PADCONF_MMC2_DAT5, (IEN | PTD | DIS | M4 )) /* gpio_137 */\
    MUX_VAL(CONTROL_PADCONF_MMC2_DAT6, (IEN | PTD | DIS | M4 )) /* gpio_138 */\
    MUX_VAL(CONTROL_PADCONF_MMC2_DAT7, (IEN | PTD | DIS | M1 )) /* mmc2_clkin  -- not used */\

    Also, in GPIO module need to program GPIO 136-138 as outputs with logic high to force

    direction of buffer used with WiFi chip.

    Pin Mux Utility software is available here.

    http://focus.ti.com/docs/toolsw/folders/print/pinmuxtool.html

    User's Guide is available here:

    http://processors.wiki.ti.com/index.php/Pin_Mux_Utility_for_ARM_MPU_Processors

    Regards,

    Michael T

    PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

  • Michael:

    I am trying to use a 3.3V SD card off MMC2 with 3.3V for VDDSHV with or without a transceiver (preferrably without a transceiver).  According to the AM3517 datasheet, the corresponding pins are powered using the VDDSHV and are LVCMOS 1.8V/3.3V compatible.  Are some of the logic levels associated with the pins (MMC2_CLK, MMC2_CMD, MMC2_DAT[0:3] not 3.3V LVCMOS compatible and use 1.8V LVCMOS levels instead?

    Section 19.2 of the AM35XX TRM indicates that MMC2 can only be used with 1.8V SD cards but that appears inconsistent with 3.3V logic levels:

    The second controller (MMC/SD/SDIO2) allows connecting MMC/SD/SDIO cards (only 1.8V cards) or
    an external device that uses the MMC/SD/SDIO interface (WLAN device for example). The second
    instance also supports an external transceiver and provides direction signals for data and command.
    Using an external transceiver device precludes 8-bit transfer mode.

    If I need a transceiver for this case, what supply should I use for the AM3517 side (3.3V to be compatible with the VDDSHV or 1.8V to be MMC2 compatible)?  Do you have any leaded transceiver recommendations?

    Thanks for helping resolve the confusion.

    Regards,

    Charlie

     

  • Charlie:

    The LogicPD AM3517 Application Board works only with VDDSHV=3.3V and it has an SDCard slot on MMC2 that is 3.3V without

    using a tranceiver.  Their are issues with a conflict with the WLAN device as detailed in this thread above.

    Please see this wiki article for more info:

    http://processors.wiki.ti.com/index.php/SD-MMC_Usage_Notes_on_AM35x

     

    Regards,

    Michael T