LP-AM243: Regarding the MMC1 and μSD card usage

I also wanted to add, it seems like adding the MMC1 instance through SYSCFG causes the program to fail...I mean it builds fine, but when running on the LaunchPad - nothing.

For example, take the standard Hello World example project (nortos, r5f).
Build it and it runs fine, you get the "Hello World" text printed to serial terminal.

But take the same Hello World example, and modify the SYSCFG to add MMCSD0 = MMC1, and yes the project builds, but now there is no activity / no text displayed...

Can I get some advice on this?

I suggest you review the SD card connections on the AM64x EVM as an example of what you need to do with respect to connecting an SD Card to the MMC1 port of AM243x. I'm not able to answer any software questions. I will assign this thread to someone on the software team once we address your hardware questions.

Regards,
Paul

Hi Peaves,

HW is the same as AM64x EVM.
I had to jumper MMC1_CLK line with a 10kΩ resistor to GND, but now they are the same.
Except for MMC1_SDWP - the write protect pin, which has no purpose on the LP-AM243x board.
(The EVM connects this pin to some GPIO expander's xINT pin, and it looks like if Chip Detect isn't valid or something it triggers this interrupt)

Before we jump into software, there is some behavior from SYSCFG I don't understand.
I imported a stock Hello World example, and opened SYSCFG, adding the MMCSD interface with settings below.
For some reason, setting "Card Type" parameter to eMMC or SD keeps the board from working (the project builds fine)
But, when the "Card Type" parameter is set to "NO_DEVICE" then the board works and I get the "Hello World" message displayed.

The only change is to SYSCFG - added the TI Drivers for MMCSD (MMC1) - but there is no SW actually using these drivers anywhere as the code is simply the imported Hello World example - no changes made. Yet why does the board freeze on boot if Card Detect is anything but NO_DEVICE?

Hi Paul,

Since I am trying to get uSD working on LP-AM243x I am referencing the TMDS243EVM schematics from the design package. (Board design is basically shared with AM64x?)

In the design I see the following.

uSD power comes from a load switch sourced from just 3.3V, generated from LM5140. There is no 1.8V switching capability on the EVM.

The load switch ENABLE pin comes from a GPIO expander controlled via I2C.

When SYSCFG is setup to use MMC1, there is no pin defined for a load switch enable. Makes sense as it is controlled via I2C here.

I understand this means the SW driver needs to handle load switch power cycling when resetting the card after things like formatting, etc.

But in the MMCSD example program for the TMDS243EVM (mmcsd_raw_io) the first function call in SW related to MMCx is MMCSD_getBlockSize().

Because of this, it looks like the load switch is enabled by default, and nowhere in the code is an I2C API used to toggle the ENABLE pin and power cycle the card.

If this understanding is correct, the MMCSD examples dont control the load switch at all, correct? 

Hi Paul,

peaves said:

The LP-AM243x does not implement a 3.3V load switch for the power supply sourcing SDIO_LDO or the connector that contains the MMC1 signals,

I understood on the TMDS243EVM design, the SD Card Load Switch enable signal comes from a GPIO expander controlled via the I2C1 interface.
The same I2C1 interface is available through the LaunchPad headers, so technically it is possible to replicate the setup on the LaunchPad...except that pressing the push-button for SOC reset won't power cycle the SD card - you would have to completely remove power to the board in that case.
(my understanding)

Right now, I think jumping into SW will provide more clarity on what is causing the MMCSD driver to hang.

With my MMCSD SYSCFG settings as shown in the image above (a few posts back), I have narrowed down my issue.

1) The main application *.c file calls Drivers_open(); which does the following (based on SYSCFG configuration):

void Drivers_open(void)
{
    Drivers_mmcsdOpen();
    Drivers_uartOpen();
}

2) In the Drivers_mmcsdOpen(); function, there is a call to MMCSD_open(); (found in "mmcsd_v0.c" in the PDK/source/drivers/mmcsd/v0 folder)

3) Since SYSCFG is setup with Card Type = SD, this function calls MMCSD_initSD();

if(phyType == MMCSD_PHY_TYPE_HW_PHY)
    {
        /* Set DLL_TRIM_ICP value to 8 */
        CSL_REG32_FINS(&ssReg->PHY_CTRL_1_REG, MMC_SSCFG_PHY_CTRL_1_REG_DLL_TRM_ICP, 8U);

        /* Reset PHY CONTROL 2 REG */
        CSL_REG32_WR(&ssReg->PHY_CTRL_2_REG, 0U);

        /* Reset PHY CONTROL 3 REG */
        CSL_REG32_WR(&ssReg->PHY_CTRL_3_REG, 0x10FF10FF);

        /* Do the calibration */
        /* Set EN_RTRIM bit */
        CSL_REG32_FINS(&ssReg->PHY_CTRL_1_REG, MMC_SSCFG_PHY_CTRL_1_REG_EN_RTRIM, 1U);
        while(CSL_REG32_FEXT(&ssReg->PHY_CTRL_1_REG, MMC_SSCFG_PHY_CTRL_1_REG_EN_RTRIM) != 1U);

        /* Set PDB to trigger calibration */
        CSL_REG32_FINS(&ssReg->PHY_CTRL_1_REG, MMC_SSCFG_PHY_CTRL_1_REG_PDB, 1U);

        /* Wait for calibration to finish */
        while(CSL_REG32_FEXT(&ssReg->PHY_STAT_1_REG, MMC_SSCFG_PHY_STAT_1_REG_CALDONE) != 1U);
    }

There is no way to switch the input to the SDIO_LDO on the LP-AM243x, and it must be powered from the same load switch that controls power to the SD Card. It is very important that you implement the proper power solution, where the same load switch cycles power to the CD Card and the SDIO_LDO. You could damage the devices if you do not do this. I do not see an easy way for you to be able to implement the proper SD Card power solution on LP-AM243x.

As mentioned before, I do not provide any software support. I will need to assign this thread to someone on the software team if you are done with hardware questions. Are you ready for me to reassign the thread?  If so, what software package are you using?

Regards,
Paul

Hi Paul,

When we design our board I will make sure we implement the load switch as you have described.
For now, since I have communication and verified R/W data to card, I believe I am comfortable with hardware on the LaunchPad.

For software, I guess at this point I want to understand what the "PHY Type" parameter in SYSCFG does, and what the difference is between the three settings.

Thanks!

We do not need to assign this question to the software team.

I will discuss this topic with our SYSCONFIG tool expert and see if they are able to confirm what I think it means.

We have two IO implementations for MMC ports. One implementation is an actual eMMC/SDIO PHY that has dedicated signal functions for each pin and only supports 1.8V IO signaling. The MMC0 port on AM243x uses the eMMCPHY buffer type, which is an example of that implementation. The other implementation uses a slightly modified LVCMOS IO cell for each pin and they support multiplexing of other signal functions and 1.8V or 3.3V IO signaling. The MMC1 port on AM243x uses the SDIO buffer type, which is an example of that implementation.

The buffer type implemented for each pin can be found in the Pin Attributes table and each buffer type has its own Electrical Characteristics section in the datasheet.

I suspect the NO_PHY option should be selected for MMC1 since it uses the SDIO buffer type rather than the eMMCPHY buffer type. I will try to confirm that is the case and let you know tomorrow.

Regards,
Paul

I finally got an answer about the NO_PHY option from the SYSCONFIG team, but it didn't make sense. Now I need to discuss the answer they provided with the MMCSD software driver team to get a better explanation.

Regards,
Paul