• State Resolved
  • Locked Locked
  • Replies 28 replies
  • Answers 3 answers
  • Subscribers 97 subscribers
  • Views 2926 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.

[FAQ] AM625 / AM623 / AM620-Q1 / AM62L / AM64x/ AM243x (ALV) / AM62Ax / AM62D-Q1 / AM62Px Design Recommendations / Commonly Observed Errors during Custom board hardware design –SD card Interface

Kallikuppa Sreenivasa
Guru**** 226935 points

Part Number: AM62L
Other Parts Discussed in Thread: AM62P, SYSCONFIG, AM62P5-Q1, AM625, SK-AM62A-LP, AM620-Q1, AM625-Q1, AM623, AM625SIP, , AM6421

Tool/software:

Hi TI Experts,

Is there a list of design recommendations or commonly observed errors for SD card Interface during Custom board hardware design?

Below are some common queries i have 

1. Pullup recommendations 

2. Power supply and Sequencing 

3. Series resistor for SD card clock output from the processor

4. Power switch for SD card reset 

MMC SW Tuning Algorithm

https://www.ti.com/lit/an/spract9a/spract9a.pdf

  • 0
    TI__Guru**** 226935 points

    Hi Board designers 

    Thank you for the interest.

    Please review the FAQ frequently for updates.

    microSD vs SD is primarily a mechanical difference, so I would not expect any changes beyond the updated card cage

    The SD Card is connected to MMC1 and the IOs associated with CMD, CLK, and DAT[3:0] are powered by VDDSHV5. The MMC1 are the IOs that must change their operating voltage dynamically based on the supported interface speed. The VDDSHV5 power source must default to 3.3V and change to 1.8V when software is ready to change the IO voltage to support faster data rates (speed, UHS-I).

    The IOs associated with SDCD and SDWP are powered by VDDSHV0. These signals only connect to mechanical switches in the SD Card socket and should be pulled high with external pull-up resistors connected to VDDSHV0. VDDSHV0 can be 3.3V or 1.8V and is not expected to change voltage.

    The SD Card is powered by a fixed 3.3V source and it has a similar internal power supply circuit that changes its IO supply from 3.3V to 1.8V when software sends a command telling the card to change the IO voltage.

    There must be a software switchable 3.3V power source that provides power to the SD Card and the VDDSHV5 power source. The 3.3V power switch is required to cycle power to the SD Card and the VDDSHV5 power rail at the same time anytime the SD Card needs to be reset. Cycling power to the SD Card is the only way it can be reset since there is no reset signal on SD Cards. Without this power switch you would need to cycle power to the entire system to reset the SD Card. The SD Card must be reset anytime it has previously operating at 1.8V and needs to return to 3.3V mode.

    Example 1:

    Support for UHS-I speed

    The SD card starts to boot at 3.3V and switches to 1.8V IO level based on the SD card used (Legacy speed or UHS-I speed) Once the Boot is complete Linux kernel will enumerate the SD card. To start the initial communication, the IO level is expected to be set to 3.3V and is done by resetting the SD card using power switch. When power witch is not implemented, the SD card IO will remain at 1.8V level and there is no way to switch back to 3.3V and communication fails.

    Only way to Ensure SD card is to have the SD card IO supply fixed to 3.3V and operate at legacy speeds.

    how to make the SD card use only 3.3V?

    (+) SK-AM62P-LP: How to Set SD Card to 3.3v only (low speed) - Processors forum - Processors - TI E2E support forums

     SK-AM62P-LP: How to Set SD Card to 3.3v only (low speed) 

    Example 2:

    Another example is where you may encounter SD card communication problem is when the watchdog timer expires and causes the processor to reset, which will return its VDDSHV5 IO voltage to 3.3V and the SD Card will still be in 1.8V mode because power didn't cycle. This is a requirement defined in the SD Card specification.

    Example 3:

    UHS-I data training

    In case data training is not successful, a retry of data training is performed. For the data training to start, the SD card is expected to be reset to the default state. When power switch to reset the SD card is not implemented, the training will not execute and communications failures will be observed calling for power cycling.

     AM625: AM625 SD card boot failed on the Linux kernel stage 

    From the schematics, it looks like the custom board doesn't have the voltage switch mechanism and is fixed at 3.3V. In that case, the UHS modes needs to be disabled in the U-Boot and Linux Kernel.

    Please see the following thread:

     SK-AM62P-LP: How to Set SD Card to 3.3v only (low speed) 

    Thanks for your guide. It was solved now after following your suggestion.

    Signal Description

    Signal Name Type Description
    SDCD Input SD Card / SDIO /e.MMC Card Detect
    SDCMD I/O SD Card / SDIO /e.MMC Command/Response Line
    SDWP Input SD Card Connector Write Protect Signal
    SDCK Output SD Card / SDIO /e.MMC Clock Signal
    SDDAT[3:0] I/O SD Card / SDIO /e.MMC data lines

    https://yannik520.github.io/sdio.html

    Peripheral Clock Output Series Resistor
    Series resistor on the clock output near to the processor clock output (MCSPI, MCASP) pins are recommended for possible reflection control (signal distortion) at the source of the clock output since the clock is also being used for retiming.
    For MMC0, MMC1, MMC2, OSPI0, GPMC0 interfaces, an unbonded pad is used (internal) for retiming. We do not use the same clock that is sent across the PCB to the attached device for our capture clock. We branch the output clock into two paths inside the device, where the clock is sent to two separate IO cells. One IO cell is connected to a package ball, which is used to source a clock to the attached device. The other IO cell is unbounded (not connected to any package ball). The clock we use as the receive capture clock is sent out through the unbounded IO cell and looped back into the device before being used as the capture clock. We do this so the clock has the same delay that is inserted on the clock going out to the attached device and the same delay that is inserted on the data coming back in from the attached device. The unbonded IO cell pad never experiences the voltage step that is produced on the source end of a PCB signal trace. A low value series resistor (0Ω to start) is recommended (provisioned) to control possible signal reflections (signal integrity purpose).

    SD card boot configuration and SDCD requirement

    SDCD is required to be pulled low externally for ROM to support SD card boot

    SD Card boot is only available on Port 1 of the MMCSD controller (MMCSD1). The IOs on this port support both
    1.8V and 3.3V operation, as well as dynamic voltage change. Thus, this port can support initial operation at 3.3V
    and remain at this voltage for legacy SD Cards, or support initial operation at 3.3V and change to 1.8V after
    ROM boot for UHS-I SD Cards.

    The MMCSD module depends on proper voltage level on the SD card detect signal (SDCD). If SDCD=1, the
    ROM will assume the card is not present and will fail the boot mode.The SDCD must be 0 for the ROM to
    continue to attempt to boot. Card detect using DAT3 is not supported. If the card is detected, the initial discovery
    phase is performed:

    SDCD pullup:

    For the SDCD customer sometimes use 10K or 47K pullup that connects to the switch that indicate the SD card presence.
    Did you have some thoughts on using 47K vs 10K.

    In many cases, external pulls are simply trying to hold a undriven signal that is part of a data bus out of the mid-supply region to limit shoot-through current in the attached input buffers, where the current logic state of these signals are not important during the undriven time since they are not being captured. That is not the case for control signals similar to SDCD, where the logic state of SDCD is constantly being monitored by the MMCSD host controller. It is important the pull-up on SDCD is strong enough to always over-drive the worst case leakage associated with the pin because this signal needs to always remains above the higher if VIH or VIHSS when a card is not inserted to prevent a false detection. Therefore, the value needs to be calculated based on the largest voltage drop allowed across the resistor for the signal to remain above the higher if VIH or VIHSS, with the worst case leakage of 10uA.

    For example, the leakage can be up to 10uA when the SDCD signal is connected to pin D19 of AM64x which implements a LVCMOS IO cell. When VDDSHV0 is operating at 1.8V, the signal needs to remain above 0.85xVDD = 1.53V. This means the resistor could not have more than 0.27V dropped across it with 10uA of leakage current. Therefore, the resistor would need to be less than 0.27V/10uA = 27k ohms. When VDDSHV0 is operating at 3.3V, the resistor would need to be less than 130k ohms.

    e2e.ti.com/.../5787915
    The SDCD and SDWP signals only connect to the card detect and write protect switches built into in the SD Card connector. These signals are pulled up to VDDSHV1 with external pull resistors and the card detect and write protect switches will connect these signals to VSS to indicate a card is detected or write protect is set. We purposefully put these signals in an always-on IO voltage domain because the MMCSD1 host controller needs to know the state of these signal even when the VDDSHV3 power rail is off or changing voltage.

    SDCD series resistor 100R
    SDCD is pulled to 3.3V_SYS and connects to the processor SDCD pin.
    When the SD card is inserted, the SD card switch connects to ground.
    In this case, the processor IO is connected directly to ground.
    A 100R series resistor is recommended for just in case use case wher the SDCD IO is configured unexpectedly as an output

    e2e.ti.com/.../am6442-am64x-sd-boot-from-mmc1-if-sdcd-pin-is-not-connected


    The AM64x MMC1 CLK, CMD, and DAT[3:0] signal functions are implemented with SDIO buffers on pins powered from VDDSHV5, which can be operated at 1.8V or 3.3V.

    The AM64x MMC1 SDCD and SDWP signal functions are implemented with LVCMOS buffers on pins powered from VDDSHV0, which can be operated at 1.8V or 3.3V.

    The SDIO buffers were designed to support dynamic voltage change. This was necessary since UHS-I SD Cards begin operating with 3.3V signaling and changes to 1.8V signaling when the SD Card is told to transition to one of the higher speed data transfer modes. For SD Card applications the VDDSHV5 power rail is typically connected to the output pin of the internal SDIO_LDO, where this LDO defaults to 3.3V and is changed to 1.8V by the MMCSD host controller at the appropriate time.

    Note: The SDCD and SDWP signal functions were assigned to pins associated with a fixed 1.8V or 3.3V power rail (VDDSHV0). A fixed IO voltage was needed for these signal functions to maintain a stable logic state going into the MMCSD host controller when the IO voltage is changed for the other signal functions. These signal functions only connect to an external mechanical switch and pull-up, so the fixed voltage VDDSHV0 power rail was a better option for powering pins associated with these signal functions.

    In your application, you should power VDDSHV5 from the same fixed 1.8V or 3.3V power source that is being used to power the IOs of the WiFi module.

    Note: Most of the AM64x IOs are turned off by default and they will not be turned on until the system has booted and software configures them. Therefore, you may need external pulls on any signals connected to the inputs of attached devices to prevent floating inputs.


    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1303956/am62a3-q1-hw-sdcd-interface/4952034 


    When using SDCD, is it possible to configure the power supply and signal level on the SDCD side to be only 1.8V?

    The SDCD signal function associated with the MMC1 port is part of the VDDSHV0 IO power domain, so this signal must operate from the same power supply that is sourcing VDDSHV0.

    The SDCD signal function associated with the MMC2 port has three pin multiplexing options, where two are part of the VDDSHV0 power domain and the other is part of the VDDSHV6 power domain. The operating voltage of this signal must be from the same source being used to power the respective IO (VDDSHV0 or VDDSHV6 power domain).

    I do not understand why this is a concern. Normally the SDCD signal is only connected to switch on the SD Card slot, where the signal is pulled high with a pull-up connected to the same power rail that is powering the associated IO and the switch in the SD Card slot will pull the signal to VSS when a card is inserted. The switch doesn't care what voltage is applied to the pull-up.

    (+) [FAQ] AM62: Power sequence of VDDSHV_MMCx - Processors forum - Processors - TI E2E support forums

    To properly support SD cards, the voltage supply to the card needs to be independently controlled to support 3.3v (for lower speed) and 1.8v (for UHS high speed) operation.  You must also be able to completely cycle power if you perform a cold/warm reset and the ROM attempts to boot from it.

    The SD Card is connected to MMC1 and the IOs associated with CMD, CLK, and DAT[3:0] are powered by VDDSHV5. These are the IOs that must change their operating voltage dynamically. So the VDDSHV5 power source must default to 3.3V and change to 1.8V when software is ready to change the IO voltage. The IOs associated with SDCD and SDWP are powered by VDDSHV0. These signals only connect to mechanical switches in the SD Card socket and should be pulled high with external pull-up resistors connected to VDDSHV0.  VDDSHV0 can be 3.3V or 1.8V and is not expected to change voltage.

    The SD Card is powered by a fixed 3.3V source and it has a similar internal power supply circuit that changes its IO supply from 3.3V to 1.8V when software sends a command telling the card to change voltage.

    There must be a software switchable 3.3V power source that provides power to the SD Card and the VDDSHV5 power source. The 3.3V power switch is required to cycle power to the SD Card and the VDDSHV5 power rail at the same time anytime the SD Card needs to be reset. Cycling power to the SD Card is the only way it can be reset since there is no reset signal on SD Cards. Without this power switch you would need to cycle power to the entire system to reset the SD Card. The SD Card must be reset anytime it has previously operating at 1.8V and needs to return to 3.3V mode. One good example where you may encounter this problem is when the watchdog timer expires and causes the processor to reset, which will return its VDDSHV5 IO voltage to 3.3V  and the SD Card will still be in 1.8V mode because power didn't cycle. This is a requirement defined in the SD Card specification.

    understood the different voltage requirement for SD card for different speed.

    From MMC1 circuit, CMD, CLK, and DAT[3:0] are pulled up to VDDSHV5, but card is powered by vcc_3v3_sys, not VDDSHV5. 

    The SD Card is always powered from a 3.3V source and it has an internal LDO/switch that changes its internal IO power rail. The SD Card IO power rail is not available outside the SD Card, so it can not be used to power the external resistors. Software will change the voltage of VDDSHV5 at the same time it tells the SD Card to change its IO voltage. Therefore, we connect the external resistors to VDDSHV5 since the resistor supply voltage must change at the same time.

    I have inserted a snapshot taken from the SD Card specification that shows an example UHS-I System Block Diagram.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers, 

    Inputs regarding power supply

    Most CMOS semiconductor inputs are not fail-safe. So, there is a good chance the same requirement applies for the attached device. We expect the IO power rail of attached devices to be powered from the same power supply that is powering the associated AM64x IOs to prevent any sequencing issues. You will need to ensure your system implementation doesn't cause problems for either of the devices if they are not powered from the same source.

    I’ve just run into a weird thing in AM62P datasheet (SPRSP89A). In Table 5-1. Pin Attributes it states that MMC1_SDCD and MMC1_SDWP balls are powered by VDDSHV0. Is this true, or a datasheet bug?

    Other MMC1 pins are powered by VDDSHV5, and for other MMCs their power is not split this way (all MMC0 is from VDDS_MMC0, all MMC2 is from VDDSHV6).

    The MMC1_SDCD and MMC1_SDWP signal do not connect to the SD Card, so they do not need to be part of the VDDSHV5 power domain. These signals typically connect to a card detect switch and write protect switch in the SD Card connector. These signals need to be pulled up to the VDDSHV0 power rail and connected to the SD Card connector switches, which short the signals to VSS when a card in inserted or the write protect slider in the write protect position. The MMCSD1 host controller would lose the logic state of these signals when the VDDSHV5 power rail changed from 3.3V operation to 1.8V operation if they were powered from VDDSHV5, since the logic state inside the AM62Px device is not valid during a voltage change on the IO power rail. So, the power rial assignment of these signals was done this way on purpose to ensure the MMCSD1 host controller would not think the SD Card was removed when the VDDSHV5 power rail changes from 3.3V to 1.8V.

    (+) AM6442: VDDSHV5 and MMC1 - Processors forum - Processors - TI E2E support forums

    The VDDSHV5 power rail is being sourced from the internal SDIO_LDO, which has its input (VDDA_3P3_SDIO) connected to the same 3.3V power supply that is sourcing the SD Card and the SDIO_LDO output (CAP_VDDSHV_MMC1) is sourcing the VDDSHV5 power rail.

    (+) [FAQ] AM625 / AM623 / AM620-Q1 / AM625-Q1 / AM625SIP: Custom board hardware design - SD card (MMC1) VDD power supply - Processors forum - Processors - TI E2E support forums

    The 3.3V power switch controlled by the three input AND gate is needed to cycle power to the SD Card and the AM62x MMC1 IO power supply. The SD Card does not have a reset input, so cycling power is the only way to reset it. You must also cycle power to the AM62x MMC1 pins anytime you cycle power to the SD Card because the SD Card inputs are not fail-safe. Having the reset capability is very important for UHS-I SD Cards because this is the only way to force the SD Card back to 3.3V mode after it was changed to operate in 1.8V mode.

    I would not recommend a direct connection to 3.3V if you plan to support UHS-I SD Cards.

    (+) [FAQ] AM62A7 / AM62A3 / AM62A1-Q1 / AM62D-Q1: Why is MMC1 powered by two different voltage supplies, VDDSHV0 and VDDSHV5 ? - Processors forum - Processors - TI E2E support forums

    The logic state of the MMC1_SDCD and MMC1_SDWP inputs to the host must not change when a UHS-I SD Card changes its IO operating voltage. It is not possible to maintain a valid logic state if these signals propagate through an input buffer of a dual-voltage SDIO cell that changes voltage. So, these signal functions are assigned to IOs that do not change voltage. These signals only connect to switches in the SD Card connector, so there is no reason for them to change voltage when the SD Card signals change operating voltage. The MMC1_SDCD and MMC1_SDWP signals should be connected to the SD Card connector switches and pulled high with external pull resistors connected to VDDSHV0. The other MMC1 SD Card signals with pull-up resistors should have their pulls powered by the VDDSHV5 source that dynamically changes voltage. 

    The MMC2_SDCD and MMC2_SDWP pins are powered from the same power rail as the other MMC2 pins. However, you should not use these pins for the MMC2_SDCD and MMC2_SDWP signal functions if you are trying to connect an UHS-I SD Card to MMC2. For this use case, these signal functions would need to implemented using one of the other pin multiplexing options that uses an IO cell powered from a fixed voltage source. The MMC2 assignments are different because we only expected MMC2 to be used with on-board fixed voltage SDIO devices similar to WiFi or Bluetooth transceivers.

     (+) SK-AM62A-LP: pull down register for SD card clock - Processors forum - Processors - TI E2E support forums

    The AM62Ax IOs are turned off by default and will not be driving the SD Card signals until software has initialized the IOs. Therefore, external pulls are required for each of the SD Card signals to hold the SD Card input buffers in a valid logic state. Software should not be turning on any internal pulls for the IOs associated with SD Card since we require external pulls on each of the signals. Turning on the internal pulls could create a condition that violates the SD Card standard if the system designer uses external resistor values that result in a pull resistance less than 10k when combined with the internal pull resistor.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers, 

    Inputs regarding MMC1 interface 

    (+) AM625: Can MMC1 support 4bit eMMC - Processors forum - Processors - TI E2E support forums

    We only support SD Cards on MMC1 because it was not timing closed for eMMC devices.

    (+) AM2432: Pin connectivity Requirements for MMC1 - Processors forum - Processors - TI E2E support forums

    All of the pins associated with the MMC1 port default to an off state, so you do not need to do anything to them if not being used.

    See the highlighted portion of the following note, which can be found below the Pin Connectivity table.

    Internal pull resistors are weak and may not source enough current to maintain a valid logic level for some operating conditions. This can be the case when connected to components with leakage to the opposite logic level, or when external noise sources couple to signal traces attached to balls which are only pulled to a valid logic level by the internal resistor. Therefore, external pull resistors are recommended to hold a valid logic level on balls with external connections.

    Many of the device IOs are turned off by default and external pull resistors may be required to hold inputs of any attached device in a valid logic state until software initializes the respective IOs. The state of configurable device IOs are defined in the BALL STATE DURING RESET RX/TX/PULL and BALL STATE AFTER RESET RX/TX/PULL columns of the Pin Attributes table. Any IO with its input buffer (RX) turned off is allowed to float without damaging the device. However, any IO with its input buffer (RX) turned on shall never be allowed to float to any potential between VILSS and VIHSS. The input buffer can enter a high-current state which could damage the IO cell if allowed to float between these levels.

    (+) AM62A7-Q1: Regardin MMC1/MMC2 Port Connection with eMMC - Processors forum - Processors - TI E2E support forums

    It is not possible.

    The MMC1/MMC2 ports only have 4 data bits, and these ports were not timing closed to operate with eMMC devices.

    The MMC0 port is the only one that has 8 data bits and supports eMMC devices.

    Please refer to the MMCSD timing section in the datasheet to see what devices and data transfer modes are supported for each MMCSD port.

    As I discuss the eMMC suppler he told me.

    “you can connect eMMC in 4-bit mode instead of 8-bit mode.

    You need to configure the eMMC driver in SoC to operate in 4-bit mode, H/W side - connect eMMC Data lines DAT0-DAT3 to SDIO lines, and other eMMC data lines (DAT4–DAT7) left unconnected in 4-bit mode”

    Is there any way we can use eMMC as a SD card with4-bit mode.

    The issue is not related to bus width.

    The timing requirements defined in the eMMC standard have differences relative to the timing requirements defined in the SD Card standard. The MMC1/MMC2 ports were not timing closed to operate with the timing requirements defined in the eMMC standard. These ports were only timing closed to operate with the timing requirements defined in the SD Card standard.

    (+) LP-AM243: Regarding the MMC1 and μSD card usage - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    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.

    (+) [FAQ] AM6422: SD Host controller driver strength - Processors forum - Processors - TI E2E support forums

    No. The drive strength of the SDIO buffer types associated with the MMC1 signals is fixed to 40 ohms.

    The IOs associated with the AM64x MMC1 port has nominal source impedance of 40 ohms. This should have been reflected in the AM64x IBIS model.

    The best way to determine optimum PCB traces impedance is to use the IBIS model from AM64x and the attached device in signal quality simulations. These simulations could be used to determine which specific PCB implementation provides adequate signal quality and signal rise/fall times (slew rate). I'm not an IBIS model expert, but fairly sure there is a model for each valid IO operating voltage. Let me know if that is not the case and I will assign this thread to our IBIS model expert.

    The IBIS model is the only way we define IO output characteristics.

    There are two options for changing the operating frequency of the MMC1 port. The MMCSD1 host controller has internal clock dividers that can be used to reduce the clock frequency of the MMC1 port, but these clock dividers may not provide much resolution in frequency changes. The other option would be to reduce the MMCSD1 function clock frequency, which may impact other subsystems that share the same clock domain inside the device. You may want to use the Clock Tree tool function in the SYSCONFIG tool to understand the internal clock structure of the AM64x device.

    (+) AM6442: Why only emmc0 can support emmc flash - Processors forum - Processors - TI E2E support forums

    Because the design team only closed timing of the MMC0 peripheral for operating with eMMC devices and only closed timing of the MMC1 peripheral for operating with SD Cards


    RE: TMDS243EVM: Is WR_PROTECT effective at 0 or 1? Is SD_DETECT effective with 0 or 1? 

    The "Standard Size SD Card Mechanical Addendum" recommends using an SD Card connector that has a card detection switch that is open when the SD Card is not inserted and closes when the SD Card is inserted. One side of the SD Card connector switch is connected to ground (VSS) and the other side of the switch is connected to the MMC1_SDCD signal which is pulled up to the respective IO supply via an external resistor. With this connection topology the MMC1_SDCD signal will be high when the card is not inserted and will be low when the card is inserted. 

    Note: VDDSHV0 is the IO supply for the AM243x MMC1_SDCD and MMC1_SDWP inputs, and VDDSHV5 is the IO supply for the other MMC1 signals. 

    The "Standard Size SD Card Mechanical Addendum" doesn't provide any specific recommendation for Write Protect.

    I do not think the MMCSD host controller has any specific logic state requirement for these inputs, and software can be configured to use an active-low or active-high signal for either of these signal functions. 

     RE: AM6442: AM6442 

    The AM64x MMC1 CLK, CMD, and DAT[3:0] signal functions are implemented with SDIO buffers on pins powered from VDDSHV5, which can be operated at 1.8V or 3.3V.
    The AM64x MMC1 SDCD and SDWP signal functions are implemented with LVCMOS buffers on pins powered from VDDSHV0, which can be operated at 1.8V or 3.3V.

    Additional Notes:

    In most cases the card detect and write protect inputs are not part of the same IO voltage domain that changes voltage (AM64x MMC1 CLK, CMD, and DAT[3:0] signal functions are implemented with SDIO buffers on pins powered from VDDSHV5, which can be operated at 1.8V or 3.3V).  In some cases there are multiple multiplexing options for the CD and WP signals, where the IOs of one option uses the same IO power rail and the other option uses another IO power rails.  In this case, the designer must select the option that uses an IO power rail that does not change voltage for the CD and WP signal functions.  The signal going into the host controller is likely to glitch during a power change (IO voltage level switching).  I am not sure if a glitch on write protect will cause a problem, but a glitch on card detect would cause the host controller to think the card was removed and the initialization process would need to be restarted.  This would result in a endless initialization loop that would restart every time you change voltage.

     RE: AM62L-PROCESSOR-SDK: Query Regarding Testing Write Protect (WP) Pin for MicroSD on SDIO_A_WP 

    The write protect signal functions can be connected to the write protect switch of a full-size SD Card connector as a way to tell software the position of the WP slider. The WP slider on a full-size SD Card is simply a piece of plastic that doesn't have any electrical connection inside the card. Write protection is purely a function of software, where it should read the logic state of the respective MMCx_SDWP signal to determine if the WP slider is in the WP position and avoid writing to the SD Card when it detects this condition. There is no hardware prevention associated with SD Card write protection.
    the Linux kernel MMC driver handles the SDWP pin, writing to the SD card will be rejected if write protection is set.
    Software doesn't need to configure anything about this pin (except pinmux), the bit19 of register MMC_CTLCFG_PRESENTSTATE directly reflects the state of the SDWP pin.

    MMC_CTLCFG_PRESENTSTATE

    SDWP when used as a GPIO

     RE: AM625: MMC interface 

    The only pins associated with MMC1 that are powered from VDDSHV0 are MMC1_SDCD and MMC1_SDWP. These pins are not connected to the SD Card. They only connect to switches in the SD Card connector and should be pulled high with an external resistor connected to the same supply that is powering VDDSHV0. The other side of the switches in the SD Card connector are connected to ground to indicate a card is present or the write protect switch is on.

     [FAQ] AM62A7 / AM62A3 / AM62A1-Q1 / AM62D-Q1: Why is MMC1 powered by two different voltage supplies, VDDSHV0 and VDDSHV5 ? 


    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1409800/lp-am243-regarding-the-mmc1-and-sd-card-usage

     AM2432: MMCSD Signals 

     TDA4VM MMC1_SDWP (SD CARD Write Protect) 

    (+) AM6421: Terminal for SD boot - Processors forum - Processors - TI E2E support forums

    From a hardware perspective, it is okay to power the MMC1 IO power rail (VDDSHV5) from a fixed 3.3V power supply when you do not plan to use UHS-I SD Cards, or you do not plan to use any of the faster 1.8V signaling data transfer modes supported by UHS-I SD Cards. You must ensure your software never tries to use any of the 1.8V signal modes if you ever attach an UHS-I SD Card. Therefore, your concern with what the ROM code does is valid.  For the proposed connection topology, you need to be sure the SD Card ROM boot code never uses any of the 1.8V signal modes if it detects a UHS-I SD Card.  I will let the ROM code team answer this question.

    VDDA_3P3_SDIO and CAP_VDDSHV_MMC1 should be connected directly to GND if the SDIO_LDO is not used to power VDDSHV5.

    The ROM code will use Legacy compatibility mode at low clock frequency 25MHz, and never attempt to increase frequency, regardless of the SD card capabilities.

    When using SDCD, is it possible to configure the power supply and signal level on the SDCD side to be only 1.8V?

    I'm not sure which MMC port you are asking about.

    The SDCD signal function associated with the MMC1 port is part of the VDDSHV0 IO power domain, so this signal must operate from the same power supply that is sourcing VDDSHV0.

    The SDCD signal function associated with the MMC2 port has three pin multiplexing options, where two are part of the VDDSHV0 power domain and the other is part of the VDDSHV6 power domain. The operating voltage of this signal must be from the same source being used to power the respective IO (VDDSHV0 or VDDSHV6 power domain).

    I do not understand why this is a concern. Normally the SDCD signal is only connected to switch on the SD Card slot, where the signal is pulled high with a pull-up connected to the same power rail that is powering the associated IO and the switch in the SD Card slot will pull the signal to VSS when a card is inserted. The switch doesn't care what voltage is applied to the pull-up.

    I understand about SDCD.
    When the VDDSHV5 is set to 1.8V using MMC1, the signals of DATA, CLK, and CMD are 1.8V, but is it possible to write to and read from the SD Card?

    SD cards begin operation at 3.3V. If using a UHS-I SD card, the software driver will request an IO voltage change to 1.8V for the higher speed modes. If you plan to support the higher speed modes of these cards, you will need to implement a dual voltage VDDSHV5 power supply that is able to change voltage at the same time the card is told to change voltage. Otherwise, you can power VDDSHV5 from a fixed 3.3V source if do not need to support the faster modes that require the signals to dynamically change from 3.3V to 1.8V. You should look at the TI EVM for an example of how to implement the SD card and VDDSHV5 power sources.

    I don't plan to use the UHS-I SD Card, so I'll consider using it with a 3.3V power supply.

    We still recommend implement a 3.3V load switch that sources the SD card and the MMC1 VDDSHV5 IO power rail with its enable controlled by a three input AND of the power on reset, AM62Ax warm reset output, and a GPIO that is pulled high until configured by software. This is needed to reset the SD card since it doesn't have a reset pin. The only way to reset an Sd card is cycle its power and the AM62Ax VDDSHV5 IO rail must be cycled at the same time to avoid non-fail-safe conditions. This implementation will reset the card anytime the system power is cycled, a warm reset is generated like in the case where a watchdog time resets the processor, or if the SD card software driver needs to reset it via a GPIO without resetting the entire system.

    The VDDSHV5 is always supplied, and the power supply of the SD card is loaded with a load switch.
    Is there a problem if the VDDSHV5 is always supplied to the SD card after SDCD is detected?
    Is it a substitute for a RESET if I put a load switch on the power supply to the SD card?

    Do I really need three inputs, SD_EN, RESETSTATz, and PORz_OUT, to power enable the SD card?
    Is it possible to achieve this with two signals, SD_EN and RESETSTATz?

    The IOs associated with both the AM62Ax device, and the SD Card are not fail-safe. This means no external circuit can source any potential greater than the potential applied to the respective IO power rail. See the "Steady-state max voltage at all other IO pins" parameter in the Absolute Maximum Ratings table in the datasheet, where the potential applied to a pin is limited to minimum of "-0.3V" and a maximum of "IO supply voltage + 0.3V".  The same limit should be applied to the SD Card pins.

    The IO power rails of attached devices need to always have the same potential applied to prevent current injection into an IO that has a potential applied greater than the limits defined in the datasheet. For example, if one device is turned on the other device must be turned on, if one device is turned off the other device must be turned off. Their IO supplies also need to track as the power source ramps up or down. The best way to ensure this condition, is to power the IOs associated with both devices from the same power source.

    For the SD Card use case, the VDDSHV5 power rail on AM62Ax, the SD Card, and any external pull-up resistors need to be powered by the load switch.

    For AM62Ax the MMC1 IOs default to an off state, so we recommend external pulls on the MMC1 signals to hold the inputs of the attached SD Card in valid logic state until the device has booted, and software configures the IOs. An external pull-down resistor is recommended for the CLK signal and external pull-up resistors are recommended for each of the CMD and DAT[3:0] signals. The external pull-up resistors should be powered from the same switched 3.3V power that is connected to the SD Card and the VDDSHV5 power rail.

    Our reset expert said the PORz_OUT would not be needed since the RESETSTATz output will satisfy all reset cases for the SD Card.

    I need to clarify my last reply. I should have said the RESETSTATz output will satisfy the power-on and warm reset functions for the SD Card. You will still need a two input AND gate to insert the software controlled GPIO reset function for the case where software needs to initiate a reset to only the SD Card.

    The software GPIO reset function originates form an IO expander on the TI hardware platform, but you could use a GPIO signal function associated with one of the AM62Ax pins if your system doesn't include the IO expander. Select an AM62Ax pin with a GPIO multiplexing option that is turned off by default. Connect a signal from this pin to the other input of the AND gate and include a pull-up on this signal so the SD Card is brought out of reset as soon as the RESETSTATz goes high. Software can configure the AM62X pin to operate as GPIO after boot and drive it low if it needs to reset the SD Card.

    (+) AM625: AM6252 Board + PMIC(TPS6521904) : SD Boot - Processors forum - Processors - TI E2E support forums

    Clarify how to boot from SD-card by AM62P EVM.

    If a system plans to support UHS-II SD Cards on MMC1, the VDDSHV5 IO supply and the SD Card must be power cycled any time the SD Card needs to be reset since it does not have a reset pin. Cycling power to the SD Card is the only way to return an SD Card back to 3.3V operation after it was previously operating at 1.8V. UHS-II SD Cards are required to begin communications with the host using 3.3V signaling so they are backwards compatible to the requirements of a legacy host. These cards can be changed to use 1.8V signaling to achieve faster data transfer speeds. The VDDSHV5 power rail must also be switched off when the SD Card power is switched off since the SD Card input are not fail-safe.

    There are two sections of circuits on the AM62P EVM schematic that accomplish the task of controlling power to the SD Card and VDDSHV5. The circuit that controls power to the SD Card can be seen on the schematic page titled "SD CARD INTERFACE".  The circuit that controls power to VDDSHV5 can be seen in a section titled "3.3V/1.8V SD CARD SUPPLY" on the schematic page titled "PERIPHERAL POWER SUPPLY -1". Both of these circuits are turned off any time reset is asserted or the GPIO connected to "MMC1_SD_EN" is driven low. This is required to force the SD Card and the VDDSHV5 power source back to 3.3V mode after a hardware or software resets, where it must reestablish communications with the host using 3.3V signaling.

    Note: the GPIO connected to "VSEL_SD_SOC" must default to a high logic state before reset is released to ensure the VDDSHV5 power supply is operating at 3.3V when SD Card communications is first initiated. This signal is only driven low at the same time the SD Card is told to switch from 3.3V to 1.8V and it shall never be allowed to go back to a logic high state until the SD Card is powered off or reset.

    Since reset is being used to turn the SD Card off, it is not possible for the SD Card to be powered up before reset is released.  The SD Card boot code in ROM is delayed for a period of time that should be long enough for the SD Card to power up and be ready for communications.

     

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Refer below  for information related to SD card reset.

    AM62P5-Q1: RESETSTAT and PORz_OUT for SD card power enable

    In the schematic of AM62P EVM, RESETSTATz and PORz_OUT are ANDed to the SD Card power enable signal.

    Customer also understand that RESETSTATz is also asserted when PORz_OUT is asserted.

    ・Is this understandig correct ?

    ・Is the circuit like this because the timing is slightly different when asserting?

    ・In that case, please tell us what  the timing between RESETSTATz and PORz_OUT.

    The system power on reset is connected to ensure the card power is forced off as soon as power is applied since this reset is expected to be valid while power supplies ramp.  The RESETSTATz is included so the SD Card is power cycled (Reset) if there is a processor warm reset source like a watchdog time-out. The GPIO is connected to allow the software driver to reset (cycle power) the SD Card.

    The RESETSTATz will not be valid until all AM62Px power rails are valid, so it is delayed relative to the system power on reset.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board designers, 

    Please Refer below for inputs related to supported standards.

    (+) AM6411: What's the right Spec. for SDIO? - Processors forum - Processors - TI E2E support forums

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1548389/am6411-what-s-the-right-spec-for-sdio

    please refer the data sheet.

    6.10.5.12.2 MMC1 - SD/SDIO Interface

    6.10.5.12.2 MMC1 - SD/SDIO InterfaceMMC1 interface is compliant with the SD Host Controller Standard Specification 4.10 and SD Physical Layer Specification v3.01 as well as SDIO Specification v3.00 and it supports the following SD Card applications:

    • Default speed

    • High speed

    • UHS–I SDR12

    • UHS–I SDR25

    • UHS–I SDR50

    • UHS–I SDR104

    • UHS–I DDR50

    We verified the TRM content internally.

    The datasheet is correct and references to 4.x in the TRM will be updated.

    Expert comments:

    I wanted to understand what got defined in 4.0 relative to 3.0.  It looks like embedded SDIO was added to 3.0, which is what we support.  It looks like UHS-II was added to 4.0, which we do not support.  So, revision 3.0 is definitely correct.

    Regards,

    Sreenivasa

  • +1 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    HI Board Designers, 

    (+) AM62L: MMC - Processors forum - Processors - TI E2E support forums

    Inputs related to supported standards

    Do all three MMC/SD buses support eMMC 5.1, SD 3.0, and SDIO Version 3.0?

    2、What does the content shown in the following picture mentioned in the TRM manual mean? Does it support SD 4.10 and SDIO 4.0? So, should we follow the data manual or the TRM?

    The next revision of the AM62Lx datasheet will be updated to show with the following list of devices and data transfer modes supported for each MMC instance.

    The MMC0 port supports connections to an eMMC device or embedded SDIO device. It does not support removable SD Cards.

    The MMC1 and MMC2 ports support connection to a removable SD Cards or embedded SDIO device. They do not support eMMC devices.

    What does the content shown in the following picture mentioned in the TRM manual mean? Does it support SD 4.10 and SDIO 4.0? So, should we follow the data manual or the TRM?

    For the supported interfaces on the MMC instances please refer to the data sheet.

    For the SDIO specifications, please follow the data sheet.

    The references to 4.x in the TRM will be updated.

    egarding the MMC interface of AM62Lx, does MMC0 support a 1-bit wide data bus or a 4-bit wide data bus? And do MMC1 and MMC2 support a 1-bit wide data bus?

    Is this a generic query or do you have an use case for the query.

    As a general answer, MMC0 should be able to support 4-bit or 1-bit and MMC1/MMC2 should be able to support 1-bit.

    I ever have similar support needs to support 2 eMMC, even one can be 4bit mode. which was supported on AM335x, but new AM62x can only support one, is it just not verified/tested? or the IP can't support 4-bit eMMC on MMC1?

    eMMC is only supported on MMC0. We did not close timing of any other MMC port to be compliant to the eMMC timing requirements.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related pulldown for Clock and SDCD 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1531431/am62p-stalls-and-crashes-during-boot-and-runtime?tisearch=e2e-sitesearch&keymatch=r0p4#

    We found that the stalls and crashes during boot and runtime were linked to the SD_CD# signal. We use the internal pull-up on that signal, but due to this https://lore.kernel.org/all/20250221091447.595199-1-mwalle@kernel.org/, the configuration was reset when the GPIO was requested, causing the SD_CD# signal to float. This probably caused some noise at lower temperatures causing an interrupt storm. We were able to reproduce this at room temperature by applying a PWM signal to the SD_CD# line.

    We would still like to know what issues could be triggered by not having the MMC1_CLK pull-down, and whether it would also be safe to not assemble it so that we would not need to redesign our board.

    In my understanding, it prevents the signal from floating before it is driven by software. We drive that signal in U-Boot and Linux, so is that MMC1_CLK pull-down necessary?

    The AM62Px IOs associated with the MMC1 signals are turned off until software boots and initializes the MMCSD1 host controller and the PADCONFIG registers associated with each MMC1 signal function. Without the external pull-down, the SD Card clock input will be floating until software has completed the initialization of the MMC1 peripheral.

    Allowing a CMOS input buffer to float is not a good design practice. Allowing this to happen can compromise long-term reliability of a device due to excess shoot-through current on any input buffer connected to a floating signal.

    A floating clock signal could also allow the SD Card to receive short duration glitches on its internal state machine clock. These short duration glitches are likely to over-clock the logic circuits in the SD Card state machine, which could cause it to enter an unexpected or locked state. SD Cards do not have a reset input. The only way to reset the SD Card is to cycle its power, which means you also need to cycle the power supply that sources the VDDSHV5 IO power rail. 

    Note the recommendation for adding a 100R series resistor for the SDCD pin.

    SD Card Bootloader Operation (SDCD pulldown)

    The MMCSD module depends on proper voltage level on the SD card detect signal (SDCD). If SDCD=1, the
    ROM will assume the card is not present and will fail the boot mode.The SDCD must be 0 for the ROM to
    continue to attempt to boot. Card detect using DAT3 is not supported. If the card is detected, the initial discovery
    phase is performed.

    (+) AM6442: AM64x SD boot from MMC1 if SDCD pin is not connected - Processors forum - Processors - TI E2E support forums

    I found the following in the TRM (rev B).....

    So a valid SDCD is required for boot. 

     https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497719/am625-custom-boards-cannot-boot-the-system-from-the-sd-card/5755145 

     https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1380597/am623-usd-card-detection-without-card-detect/5275192 

     AM62A3-Q1: HW:SDCD Interface 

     https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1414652/faq-am6442-am6442-mmc1/5425202 

    (3) AM2432: MMCSD Signals - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    The SDCD and SDWP signal functions are defined by industry specifications. It is important not to confuse the physical layer signal requirements with the IP register definitions. 

    Signal/Physical Layer Definitions:

    Card Detect (MMC1_SDCD)

    0 (Logic Low - VSS) = Card Detected

    1 (Logic High - VDD) = No Card Detected

    Write Protect (MMC1_SDWP)

    0 (Logic Low - VSS) = Write Protection Disabled (Write Enabled)

    1 (Logic High - VDD) = Write Protection Enabled (Write Disabled)

    (3) AM2431: Questions about SD Card IF(MMCSD1) - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    I confirmed with our SDK team as well that there is no explicit MMC clock control. So yes, it is a free running clock. 

    EMI/EMC immunity can be designed into the PCB. There are many applications that have continuously or nearly continuous clocks that can pass EMI/EMC requirements. Does your customer need any help with that aspect of their design?

    If the interface is used at any significant duty cycle during emissions testing, the clock will be there and so will any EMI issues. So it is important to design for low noise anyhow. 

    (+) AM6421: SD Card (primary) and Ethernet (backup) boot not working - Processors forum - Processors - TI E2E support forums

    Please check this issue from the EVM User's Guide:

    By spec, the MMC interface needs to include external pullups for stable operation.  In silicon revision 2.0 of AM64x, the ROM does not set any internal pulls and relies on external board pulls.  Rev C of the EVM has v2.0 silicon.  On previous boards (at least the ones i have), there is v1.0 AM64x silicon, which does enable internal pulls on the MMC signals.  This is why some of the previous boards i had worked fine.

    I think the reason why a subsequent boot works is that power is stable to the card at that point (after long delay from the backup boot mode) and some of the data signals may have some leakage so the voltage state may be different than at power on.  Regardless of a board power-on event or a warm reset, power to the card is cycled using a load switch on the board, so when the ROM initially access it, without the pull- ups, IO power just completed ramping and data signal may not be at a valid level.  Add the pullups will ensure valid levels and more robust operation.

    I still would not recommend ethernet boot for the reasons i mentioned below.  You may get inconsistent results across multiple devices.   It is recommended to use UART or USB-DFU.

    I am able to boot from SD card as primary boot device after I mounted all pull ups.

    As suggested, we will use USB-DFU/UART for installing image to fresh eMMC.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    (36) [FAQ] AM625: What's the purpose for the pull down R on MMC_CLK? - Processors forum - Processors - TI E2E support forums

    [FAQ] AM625: What's the purpose for the pull down R on MMC_CLK?

    Most of the IOs associated with the AM62x device default to the off state, which means any attached device input without an internal pull resistor would be floating until software configures the pin to drive the signal. We use an external pull-down rather than an external pull-up since the clock signal is held in a low logic state when paused.

    Pull down vs pull up for SD card clock

    Because there are cases where the clock is stopped or paused in a low logic state and the pull-down option is consistent with this logic state.

    SK-AM62A-LP: pull down register for SD card clock

    Clock line of SD card is pull down on EVM. Can you please let us know the reason? Padconfig setting is also internal pull down in SDK.

    The AM62Ax IOs are turned off by default and will not be driving the SD Card signals until software has initialized the IOs. Therefore, external pulls are required for each of the SD Card signals to hold the SD Card input buffers in a valid logic state. Software should not be turning on any internal pulls for the IOs associated with SD Card since we require external pulls on each of the signals. Turning on the internal pulls could create a condition that violates the SD Card standard if the system designer uses external resistor values that result in a pull resistance less than 10k when combined with the internal pull resistor.

    Because it is pulled down by R315 on another page of the schematic.

    You should never have a pull-up and pull-down connected to a digital signal at the same time since this would result in a mid-supply steady-state condition, which is not allowed on most CMOS inputs

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to SD card pullups

    (+) [FAQ] AM620-Q1: What's the max current input (or output) for SDIO DATA/CMD line? - Processors forum - Processors - TI E2E support forums

    AM620-Q1: What's the max current input (or output) for SDIO DATA/CMD line?

    We define output current as IOL and IOH parameters, which is the minimum Low Level Output Current and High Level Output Current for which the device is able to maintain the specified VOL and VOH values. Values defined by these parameters should be considered the maximum current available to a system implementation which needs to maintain the specified VOL and VOH values for attached components.  You will need to use the AM62x IBIS models in a simulation to determine VOL or VOH levels for a specific current.

    We plan to include the following input leakage note in the next revision of the datasheet.  Hopefully, it helps explain what this parameter defines.

    This parameter defines leakage current when the terminal is operating as an input, undriven output, or both input and undriven output,
    without internal pulls enabled.

    Most of the AM62x pins will be turned off after power-up. This means the input buffer is disabled, the output buffer is disabled, and the internal pulls are disabled.  Please reference the Pin Attributes table in the datasheet to see the initial power-up state of each pin. You may need to have external pull resistors on any signals that connect to inputs of attached devices to prevent them from floating until software configures the associated IO cell.

    You can use the AM62x internal pull resistors if an external resistor is not required to hold inputs to a valid state while waiting for software to configure the internal resistors. 

    The max input leakage is defined for the two worst-case conditions, which occurs when the voltage applied to the input is 0V or the IO power rail potential. See the test conditions associated with the input leakage current parameter. We do not define input leakage at VIL or VIH, but the leakage current will decrease as the voltage potential applied to the input moves away from either of the two test conditions.

    Recommended pullup for SD card interface 

    Is there a reason for 47K vs 10K

    Use of 47K ensures the SD card interface is within the SD card specifications in use cases where the SOC internal pulls are enabled unexpectedly.

    You should have an SD Card receptacle connected to MMC1 and the MMC1_SDCD signal should be pulled high by the same source that is sourcing VDDSHV0. The switch in the SD Card receptacle should be the configured such that it connects the MMC1_SDCD signal to VSS when a card is inserted. The high to low transition on the MMC1_SDCD signal will tell the host controller a card has been inserted.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to supported interfaces on MMC0 and MMC1

    You should be looking at the MMC0 - eMMC Interface section in the Timing and Switching Characteristics section of the datasheet.  This is where the datasheet defines valid modes of operation.

    (+) AM6442: Why only emmc0 can support emmc flash - Processors forum - Processors - TI E2E support forums

    Because the design team only closed timing of the MMC0 peripheral for operating with eMMC devices and only closed timing of the MMC1 peripheral for operating with SD Cards.

    AM64x does not support SD Card on MMC0. More details provided below.

    It was not possible to close timing on the MMC0/MMC1 ports for them to be compliant with both eMMC and SD Card standards, so MMC0 timing was optimized for eMMC and MMC1 timing was optimized for SD Card.  You may find MMC0 timing is compliant to timing requirements of some SDIO devices, but you would need to perform a detailed timing analysis using system specific PCB delays, switching characteristics, and timing requirements of each device to confirm

    The external pull requirements vary based on the PHY implemented for a specific host port and the attached device. The PHY implemented for the AM64x MMC0 port only supports eMMC devices and does not require external pulls to hold the attached device in a known state until the port is initialized because the MMC0_CLK pin is driven internal pulls are automatically turned on as soon as the AM64x device is powered. That is not the case for MMC1.  

    (+) AM6442: Does MMC1 controller support Wifi SDIO devices ? - Processors forum - Processors - TI E2E support forums

    There should not be any issue connecting an SDIO device to MMC1 from the hardware perspective as long as you do not violate the timing conditions and timing requirements defined in the datasheet for the respective mode of operation.

    The MMC1 - SD/SDIO section of the AM64x datasheet says "MMC1 interface is compliant with the SD Host Controller Standard Specification 4.10 and SD Physical Layer Specification v3.01 as well as SDIO Specification v3.00 and it supports the following SD Card applications:" then provides a list of supported data transfer modes.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to UHS-I SD card interface: Resetting SD card supply and processor IO supply

    I am using power switch to reset the SD card. When the SD card is reset the SOC IO supply is present. 

    Is there a performance concern with this configuration

    The processor MMC1 (VDDSHV5) or MMC2 (VDDSHV6)  power rail and the external pull-ups is required to be powered from the output of the SDIO_LDO. 

    The SD Card pins are not fail-safe so the input of SDIO_LDO needs to be power from the same switched power source used to power the SD Cards. 

    This will cycle power to the IOs and the external pull-ups at the same time so they are not sourcing any potential to the SD Card pins when it doesn’t have power.

     

    Having a potential on the SD Card pins when not powered may hold the SD Card power rail above the maximum voltage allowed to ensure a valid reset on power up or power-cycle.

     

    Please refer below specifications

    https://www.vikingtechnology.com/wp-content/uploads/2021/03/SDCard_Phison_PS8210_Industrial.pdf

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    FYI regarding output parameters

    (+) AM6411: MMC/SDIO drivers rise/fall timing and slew rates - Processors forum - Processors - TI E2E support forums

    Could you provide the rise/fall times and slew rates of drivers (IO cells) of MMC1 (SDIO) at 3V3 and 1V8 in different modes (specially default mode at <25MHz)?

    We do not define output rise/fall times because these parameters depend on the actual system implementation. You will need to use the IBIS model for the respective AM64x pin and simulate the rise/fall times based on your actual PCB load.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    It appears you have a question about CAP_VDDSHV_MMC1.I will explain how the SDIO LDO module works, but will leave the complete power supply connectivity review for the EVM team.

    SDIO LDO has a 3.3V input (VDDA_3P3_SDIO) which should be sourced from an external 3.3V power switch that also provides power to the SD Card. The 3.3V power switch is controlled by a GPIO so the software driver can cycle power to the SD Card and SDIO LDO anytime the SD Card needs to be reset. Cycling power to the SD Card is the only way to reset it since SD Cards do not have a reset pin.

    Note: The external 3.3V power switch must be enabled by default if you plan to support SD Card boot since the ROM code doesn’t know which GPIO your End Equipment uses to control the power switch.

    The output of SDIO LDO (CAP_VDDSHV_MMC1) needs to be connected to MMC1 IO supply pins (VDDSHV5) and external 3.3uF de-coupling capacitor. The SDIO LDO passes 3.3V from the input to the output by default, which applies 3.3V to VDDSHV5. The host controller will initially communicate with the SD Card using 3.3V signaling. If an UHS-I SD Card is detected, the card will be told to reduce its IO voltage to 1.8V before the host controller resumes communication using a higher speed transfer mode. After telling the card to change its IO voltage, the software driver will also tell SDIO LDO to change its output voltage from 3.3V to 1.8V. This changes the MMC1 IO supply to 1.8V so the host controller can resume communications using 1.8V signaling.

    You can see this connectivity in the AM64x EVM schematic, where the external 3.3V power switch is implemented 

    Also note: The IOs associated with MMC1_SDCD and MMC1_SDWP pins are powered from VDDSHV0 rather than VDDSHV5. So any pull-ups connected to signals associated with these pins should be sourced by the same supply that is sourcing VDDSHV0.

    Regards,

    Inputs related to connection of internal LDO

    (7) AM6442: VDDSHV5 and MMC1 - Processors forum - Processors - TI E2E support forums

    The VDDSHV5 power rail is being sourced from the internal SDIO_LDO, which has its input (VDDA_3P3_SDIO) connected to the same 3.3V power supply that is sourcing the SD Card and the SDIO_LDO output (CAP_VDDSHV_MMC1) is sourcing the VDDSHV5 power rail.

    (6) AM6412: CAP_VDDSHV_MMC1 - Processors forum - Processors - TI E2E support forums

    A 3.3uF capacitor provides the correct voltage transition timing when the SDIO-LDO output (CAP_VDDSHV_MMC1) is required to change from 3.3V to 1.8V.  A 4.7uF capacitor may not be discharged from 3.3V to 1.8V before communications with the SD card resumes after it is told to change IO operating voltage.

    If you are not using the internal SDIO LDO to source VDDSHV5, you should connect VDDSHV5 to the appropriate IO supply and connect both VDDA_3P3_SDIO and CAP_VDDSHV_MMC1 directly to VSS. A 1uF de-coupling capacitor is required for CAP_VDDS5.

    The max quiescent current expected would be 365 uA.

    There are no disadvantages for not suppling power to SDIO_LDO when not used to power VDDSHV5. However, the VDDA_3P3_SDIO and CAP_VDDSHV_MMC1 pins should be connected to VSS when it is not powered. 

    If the VDDSHV5 IO group (L20, J19, K21, L21, K19, K18) is not used (unconnected), Is it necessary to supply power to VDDSHV5?

    Needed for boundary scan?

    It would definitely break boundary scan for all pins powered by VDDSHV5.

    (+) AM6442: AM6442 MMC1 voltage - Processors forum - Processors - TI E2E support forums

    You should not be using the SDIO_LDO to power the IO power rail of the Wi-Fi module.

    SDIO_LDO was only design with enough current capacity to source the AM64x IOs.

    You should not use SDIO_LDO when connecting MMC1 to a Wi-Fi module and the interface is operating at a fixed voltage.

    You should connect VDDSHV5 and the Wi-Fi module IO to a common fixed 1.8V power source.

    In this case, you would not be using SDIO_LDO. So, you would connect the VDDA_3P3_SDIO and the CAP_VDDSHV_MMC1 pins to VSS as described in the Connectivity Requirements table found in the datasheet.

    (6) TMDS64GPEVM: SD card: no support for card's volts - Processors forum - Processors - TI E2E support forums

    It looks like you may have connected the SD Card power supply directly to a 3.3V source rather than connecting it through a GPIO controlled power switch. If so, this will be problematic because there is no way to reset the card back to 3.3V mode when it needs to be re-initialized after previously being configured to operate at 1.8V. Please confirm if a GPIO power switch was implemented in your system to control the 3.3V power source applied to the SD Card power rail and the SDIO_LDO input (VDDA_3P3_SDIO).

    SDIO_LDO input (VDDA_3P3_SDIO), SDIO_LDO output (CAP_VDDSHV_MMC1), and MMC1 IO supply (VDDSHV5) are recommended to be connected to support USH-I SD card

    (6) AM6442: Don't need to connect 3.3uF capacitor on CAP_VDDSHV_MMC1 if MMC1 is not used ? - Processors forum - Processors - TI E2E support forums

    his pin must be connected via a 3.3-μF ±20% capacitor to VSS when the SDIO_LDO is being used to source VDDSHV5. This pin may be connected directly to VSS when VDDA_3P3_SDIO is also connected directly to VSS.

    VDDSHV5 should be connected to a fixed 1.8V or 3.3V IO power source when it is not being sourced from SDIO_LDO.

    IO power supply assignments are defined in the POWER column of the Pin Attributes Table. You can use this information to determine which pins and signal functions assigned to them are powered by VDDSHV5.

    Regards,

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to SD card pulls

    (+) AM625: Sysconfig issue about AM6254 - Processors forum - Processors - TI E2E support forums

    How did we design this pull-up resistance state?

    SD cards were designed with the expectation they would be connected to a host that is always driving or pulling the signals to a valid logic state. However, that is not the case for AM62x because the pins associated with these signals have multiple signal functions. The IOs for these pins are turned off by default since the pins are not dedicated to the SD Card signal functions. This is done to prevent any contention with the actual use case. For example, there is a very good chance you would not want the pin associated with CLK to be driven if you were using it with the GPIO signal function. The internal pulls are also turned off for the same reason, as they may conflict with the actual use case.

    The SD Card inputs can't be left floating until software boots and configures the AM62x IOs, so external pulls are required to hold the SD Card inputs in a known state. There is no reason for software to turn on the internal resistors if an external resistor is already connected.

    We typically recommend an external 47k pull-up on CMD and each DAT signal, and an external 10K pull-down on CLK.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to boot delay when SD card interface is used:

    (+) AM62A7: The boot time slows down by about 1 second when no SD card is inserted. - Processors forum - Processors - TI E2E support forums

    (+) AM62P: sdhci-am654 fa00000.mmc: Power on failed - Processors forum - Processors - TI E2E support forums

    The 1.5 seconds delay is coming because of the following commit:

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?id=7ca0f166f5b2

    As explained in the commit message, it may not be possible to remove the delay as long as the SDHCI1 node is enabled in the DTS.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to PMIC TPS6593 configured for SD card functionality supporting uHS-I SD card

    (2) TPS6593-Q1: LDO1 output for SD card interface - Power management forum - Power management - TI E2E support forums

    AM62Ax SD card interface using TPS6593 PMIC

    SOC

    PMIC

    https://www.ti.com/lit/ug/slvucm3/slvucm3.pdf

    3.2 Control Mapping

    GPIO9 and GPIO11 are configured to enable LDO2 (VPP) and LDO1 (SD card interface). The TPS65931211-Q1 enables LDO1 when a rising edge is detected on GPIO11 after nRSTOUT is released and PMIC is in Active state. Similarly, the PMIC enables LDO2 when a rising edge is detected on GPO9 after nRSTOUT is released.

    GPIO5, GPIO6 and GPIO10 are configured to set the output voltages on some of the PMIC power resources and the state (high or low) for these GPIOs need to be set before the assigned rail turns ON. GPIO5 is configured to set the output voltage on LDO1 to support UHS-I SD cards (3.3V or 1.8V). GPIO6 is configured to set the voltage on the multiphase Buck1/2/3 to support either VDD_CORE voltage (0.75V or 0.85V). GPIO10 is configured to set the voltage on Buck4 to support LPDDR4 (1.1V) or DDR4 (1.2V).

    Note: In case SD card power control switch that switches the SD card power and also provides Low-High transition for PMIC is not implemented, LDO1 output will be disabled.

    When using the TDA4VE, I have some doubts about the schematic screenshot below—if The Using Card is not a high-speed card , that means the VDD_SD_DV must stay 3.3V .

    then both LDOs on U8 will operate simultaneously. Would directly connecting OUT1 at 3.3V and OUT2 at 1.8V cause any problems? 

    (EN1 and EN2 of U8 both HIGH.)

    No issue with this configuration.  When the 3.3V output is enabled, the 1.8V regulator (also enabled) will see the output above its regulated voltage threshold and disable the internal FET (effectively disabling the 1.8V regulation).

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to the clock transition

    (+) AM625: SDIO_CLK quality check - Processors forum - Processors - TI E2E support forums

    On customer board, connect MMC2 with WIFI module via serial inductance to eliminate overshot, probe on inductance of AM62 side, the clock signal has some reflection on edge, on WIFI side, the rising/falling edge is clean, we think on WIFI side should be OK, will the AM62 side clock quality impact AM62 SDIO receiving data?

    In other word, as the SDIO_CLK is a output signal, will AM62 MMC use the external clock for receiving?

    , 

    The AM62x MMC2_CLK pin is an output only. We implement another IO on the device, which is not connect to package balls. This undocumented IO is used to loop back the clock for retiming purposes. Therefore, you do not need to worry with non-monotonic transitions on the AM62x end of the signal trace.

    So same for MMC0_CLK and MMC1_CLK?

    Yes.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to UHS-I receive mode training 

    (+) [FAQ] AM625 / AM623 / AM620-Q1 / AM625-Q1 / AM625SIP: UHS-I SDR104 Receive mode timing - Processors forum - Processors - TI E2E support forums

    [FAQ] AM625 / AM623 / AM620-Q1 / AM625-Q1 / AM625SIP: UHS-I SDR104 Receive mode timing

    Datasheet section 7.11.5.16.2.7 only provides Transmit Mode timings.
    My customer is asking for receive mode timings.

    The AM62x device only supports data training for UHS-I SDR104, which means the setup and hold requirements associated with the AM62x input data path are not fixed values that can be defined in the datasheet.

    In case data training fails, the SD card interface driver tries to restart  the communication sequence starting from the legacy speed. When Load switch is not provided, the repeat of training is likely to not happen resulting in communication and/or boot failure since the only way to reset the SD card is to cycle the power.

    (+) AM625: MMC1/MMC2 USH-I SDR50 SDR104 receive mode timing requirements - Processors forum - Processors - TI E2E support forums

    These data transfer modes require data training to center data capture in the center of the data valid window, so the timing requirements are not fixed to specific values.

    This is defined in the "MMC1/MMC2 DLL Delay Mapping for all Timing Modes" table.

    (+) AM625: HW Design to Support SD UHS-I Mode - Processors forum - Processors - TI E2E support forums

    (+) AM6422: spread spectrum clocking: restrictions when using UHS-I SD Cards - Processors forum - Processors - TI E2E support forums

    (+) AM6411: What's the right Spec. for SDIO? - Processors forum - Processors - TI E2E support forums

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to SD card boot during board-bring-up

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1467511/am6421-sd-card-primary-and-ethernet-backup-boot-not-working/5637121

     I am able to boot from SD card as primary boot device after I mounted all pull ups.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1380597/am623-usd-card-detection-without-card-detect/5275192

    Refer to "broken-cd" property in MMC node as noted in the referenced e2e in my last reply.
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/Documentation/devicetree/bindings/mmc/mmc-controller.yaml?h=10.00.04#n37

     https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1303956/am62a3-q1-hw-sdcd-interface 

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers, 

    FYI.

    The configuration of MMCSD2 was not quite clear. In the datasheet and dev-data.c, we could only find the description of MMCSD0/1.

    Do we have related documents for customer to debug MMCSD2? 

    (+) AM62x: MMCSD2 Configuration - Processors forum - Processors - TI E2E support forums

    MMCSD2 is basically another instance of MMCSD1 with respect to it supporting SD Card and SDIO devices operating in one of the data transfer modes listed in the datasheet.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers, 

    Inputs related to recommended pulldown value for the attached memory device pulldown:

    Memory interface peripherals pulldown value AM62x or Am64x 

    I have a few customer using 1K pulldown for some of the signals from the SOC mostly for memory interfaces.

    Wanted to get your thoughts on the use case.

    The current draw from the IO seems more and could affect the VOH. Any thoughts on the use case please.

    I agree the 1k resistor could impact the VOH level to the attached device, and it could also impact our VIHSS level if our receiver is turned on. 

     

    The customer should run a simulation of their system using the IBIS models of each device connected to the signal to determine if the output can achieve an appropriate levels after accounting for the output buffer drive capability, worst case pull resistance, and worst case leakage of all attached components.  I would suggest they consider a 4.7k if there is a concern with 10k.

    information on sizing of external pulls.

    A resistor must be selected that is able to hold the signal above the steady-state high (VIHSS) or below the steady-state low (VILSS) based on the signals worst-case combination of leakage, which will be the sum of the max leakage of all attached devices. 

    For example, if it is assumed AM62P is connected to a single UART device that has a max leakage of 5uA when operating at 1.8V.  The worst-case leakage would be 10uA + 5uA = 15uA.  VIHSS for the LVCMOS IO cell operating at 1.8V is 0.85 x VDD = 1.53V.  A pull-up resistor value would need to be at less than 18k ohms to hold the voltage above 1.53V for a worst-case leakage of 15uA.  It is suggested to use a value that is less than 18K ohm for this example.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers, 

    AM644x, AM243x, AM62L VDDA_3P3_SDIO (internal LDO input connection)

    The VDDA_3P3_SDIO connects to the SD card power switch output.

    I assume VDDA_3P3_SDIO is treated as a supply rail and the slew rate requirements for the other supply rails is applicable for the VDDA_3P3_SDIO supply input.

    Any thoughts please.

    Yes.  The ramp limit is associated with the ESD circuit implemented on each power rail, so the same limit applies to all power rails.

    Additional inputs on SOC IO ESD protection

    The IOs associated with the AM62Px device are not fail-safe. This means no external circuit can source any potential greater than the potential applied to the respective IO power rail. See the "Steady-state max voltage at all other IO pins" parameter in the Absolute Maximum Ratings table in the datasheet, where the potential applied to a pin is limited to minimum of "-0.3V" and a maximum of "IO supply voltage + 0.3V".

    The IO power rails of attached devices need to always have the same potential applied to prevent current injection into an IO that has a potential applied greater than the limits defined in the datasheet. For example, if one device is turned on the other device must be turned on, if one device is turned off the other device must be turned off. Their IO supplies also need to track as the power source ramps up or down. The best way to ensure this condition, is to power the IOs associated with both devices from the same power source.

    The ESD protection circuits associated with an IO will turn on if the potential applied is greater than IO supply voltage+0.3V.  This condition will inject current from the external voltage source through the ESD circuits to the IO power rail. We do not allow injection current through the ESD protection circuits because they were only designed to protect the device from short-duration ESD events similar to what would be introduced by a Human Body Model to account for device handling and a Charged Device Model to account for PCB assembly equipment. The ESD protection circuits are not designed for steady-state DC current. They also were not designed to provide any system-level ESD protection once the device has been installed on a PCB.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to AM6421: RESETSTATz output during ROM boot

    During a successful QSPI boot, I have captured the following signals: MCU_PORz, RESETSTATz, OSPI_CLK, OSPI_CS.  I'm observing that roughly 35mS after RESETSTATz goe high it has a 160uS period where it drops low.  Looking at the logic capture and identical timing characteristics it appears that ROM boot occurs twice.  Is this expected behavior?

    I have captured the signals as you requested MCU_RESETSTATz drops low at the same moment as resetstatz, but the others remain unchanged.  I have also provided a couple of pages of the schematic that include power and reset to the processor.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1607595/am6421-resetstatz-output-during-rom-boot/6203293 

    could you explain *what* you're booting? If this is e.g. U-Boot or a SBL with provisions for the i2368/i2331 errata, the bootloader will warm-reset the processor after the first boot, causing the ROM to load the bootloader image a second time. This also matches PORz_OUT remaining high, while RESETSTATz and MCU_RESETSTATz briefly go low.

    this warm reset is implemented in the SBL, not in the ROM. You could check your own bootloader for this code sequence:

    https://github.com/TexasInstruments/mcupsdk-core/blob/6a622a5c2729c5ad10ba066646944609dc0c64bb/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c#L71

    The implementation for Bootloader_socResetWorkaround is here:

    https://github.com/TexasInstruments/mcupsdk-core/blob/6a622a5c2729c5ad10ba066646944609dc0c64bb/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c#L1249

    If your application doesn't (and wont ever) use PRU-ICSSG or CPSW, I guess you could disable this code.

    What happens is the boot ROM loads your code, the code detects the reset reason was a cold boot or a PORz, and executes a warm reset. Boot ROM loads your code for the second time, the reset reason is a warm boot, and your bootloader continues.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to IO supply switching to support UHS-I speed

     https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1463927/dra821u-dra821u4/5617678 

    SD card supports only 3.3V, thus will not support UHS-I data rates.  Ensure the SDCard interface is NOT switching to higher speeds (requires lower IO voltages).  I think the default software from TI reads the card and switches to lower voltage/higher speeds if supported by the card.  Customer will need to disable that switch, as their board will not support.

    Also the EVM (and TI software) expects EEPROM on board to contain configuration information.  If the EEPROM does not exist, then customer can remove that section of code and provide any missing information via other mechanism.  

    I/O Power domain of 3.3 V which you have given only supports SD and HS speed mode.However,to support UHS-1  speed mode ,only I/O voltage of 1.8V is supported.

    According to your hardware schematics,a fixed I/O voltage of 3.3V is present thus preventing UHS1 speed modes.

    I am also attaching the supported I/O voltage to speed mode relationship in the figure below.

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to IO supply for IO group supply and SD card supply 

     RE: AM625: SD Card I/O Group Load Switch Logic Issue 

    The IO cells associated with the VDDSHV4, VDDSHV5, and VDDSHV6 power rails were designed to support dynamic voltage change.

    Please read the "Power-Up Sequencing – Supply / Signal Assignments" table note associated with waveform D.

    We also attempted to represent this capability in power-up and power-down sequence diagrams, where these three power rails are represented with a continuous grey area in waveform D that that was meant to indicate these power rails can change without any dependency on any other power rails.

    The load switch in question is required to ensure the SD Card can be reset by cycling its power anytime there is a warm reset or software needs to re-initialize communications with the SD Card. This is needed since the SD Card does not have a reset input, and cycling power is the only way to force the SD Card back to 3.3V signaling mode after being placed in 1.8V signaling mode. The VDDSHV5 power rail needs to have its power cycled at the same time as the SD Card, so the entire peripheral is power cycled together.

     AM623: AM623 and AM62L SDIO voltage control 

    Inputs related to IO supply for IO group connection when not used.

    AM2432: Unused SDIO VDDSHV5 decoupling capacitors and connections - Processors forum - Processors - TI E2E support forums

    The VDDSHV5 IO power rail supports being turned off for short periods of time and supports dynamic voltage change as required when cycling power to reset an SD Card or when changing the IO operating voltage of an SD Card. However, the VDDSHV5 IO power rail is expected to be always powered for any other use or non-use cases. VDDSHV5 should always be connected to a valid 1.8V or 3.3V IO power supply.

    Decoupling capacitors are still required on the VDDSHV5 power rail even when the associated IOs are not used because each IO power rail sources an internal IO bias LDO.

    A decoupling capacitor is also required on CAP_VDDS5 when VDDSHV5 is connected to a 3.3V power source. See the note associated with the CAP_VDDS5 signal description in the AM243x datasheet for more information on decoupling capacitor requirements for the CAP_VDDS5 pin.

    The custom board design being worked on will not have SDIO MMC1. Reviewing the Connectivity requirements i have the following understanding:

    MMC1 Unused. All pins on this interface default GPIO off/off/off. Thes pins will be left as No connects.

    SDIO_LDO will not be used. VDDA_3P3_SDIO and CAP_VDDSHV_MMC1 must be connected to Ground. 

    VDDSHV5 Looks like it is for MMC1 module. If the MMC1 module is not used How should this Power rail be connected?

    Yes. As I mentioned in my previous reply, each power rail is supplying power to an internal IO bias LDO. This is a different LDO than SDIO_LDO which is powered from the VDDA_3P3_SDIO power rail.  It is not possible to leave the internal IO bias LDO unpowered for long durations. We only support it being powered off for a short duration when the VDDSHV5 IO bank is connected to an SD Card and the only way to reset an SD Card is cycle its power. The SD Card pins are not fail-safe so we must turn off the AM243x IOs and any pull-ups connected to the SD Card when its power is cycled off for a short duration to reset the SD Card. This use case is the only time we allow the VDDSHV5 to be powered off while other portions of the device remain powered.

    Note: 

    The explanation is valid for fixed dual-voltage IO supply for IO group supplies (VDDSHV0, VDDSHV1, VDDSHV2, VDDSHV3, VDDSHV4 (for AM64x) and and Dynamically switched dual-voltage IO supply for IO group supplies  (VDDSHV4, VDDSHV5, VDDSHV6 - depending on the processor family)

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to recent debug

    (+) SK-AM62P-LP: How to Set SD Card to 3.3v only (low speed) - Processors forum - Processors - TI E2E support forums

    (+) [FAQ] AM6548: AM6548 not booting from eMMC - Processors forum - Processors - TI E2E support forums

    In AM65x devices, the MMC0_SDCD pin was unexpectedly configured with DEVICE_PINMUX_PULL_ENABLE and DEVICE_PINMUX_PULL_UP, causing an internal pull-up resistor to conflict with external pull-down resistors and preventing proper eMMC boot operation.

    As i mentioned please use a strong pull (100R - 1K) as pulldown

    The pulldown value is to ensure there is a current limit in case the IO is configured as output unexpectedly.

    (+) AM625: Custom boards cannot boot the system from the SD card - Processors forum - Processors - TI E2E support forums

    (+) OCTVO-3P-OSD62X: Issue with VDD_SD dropping to 1.8V when SD card inserted (OSD62x-PM with AM625) - Processors forum - Processors - TI E2E support forums

    (10) OCTVO-3P-OSD62X: SD card boot support for OSD62x - Processors forum - Processors - TI E2E support forums

    (+) AM625: AM6254- stuck while booting from SD card - Processors forum - Processors - TI E2E support forums

    (+) AM62A7-Q1: SD card boot issue in customized board - Processors forum - Processors - TI E2E support forums

    (+) AM62A7: SD card boot fails, and DDR-margin-fw cannot be loaded - Processors forum - Processors - TI E2E support forums

    (+) AM625: AM625 SD card boot failed on the Linux kernel stage - Processors forum - Processors - TI E2E support forums

    From the schematics, it looks like the custom board doesn't have the voltage switch mechanism and is fixed at 3.3V. In that case, the UHS modes needs to be disabled in the U-Boot and Linux Kernel.

    Please see the following thread:

     SK-AM62P-LP: How to Set SD Card to 3.3v only (low speed) 

    (+) AM623: SD card boot failure on custom board - Processors forum - Processors - TI E2E support forums

    (+) AM6421: SD Card (primary) and Ethernet (backup) boot not working - Processors forum - Processors - TI E2E support forums

    (+) AM625: SD Card Flash eMMC - Processors forum - Processors - TI E2E support forums

    When SD card does not work, check if the following workarounds helps:

    3.2.2.16. MMC/SD — Processor SDK AM62x Documentation

    (+) AM625: The SD card capacity - Processors forum - Processors - TI E2E support forums

    AM6254 doesn't have limitation on SD card capacity.

    (10) AM625: No boot to SD - AM625 - Processors forum - Processors - TI E2E support forums

    (+) AM625: AM62X - Processors forum - Processors - TI E2E support forums

    (10) TDA4VM: J721EXSKG01EVM: Needed information regarding support for 128GB microSD Card and Compatible SD Card Class - Processors forum - Processors - TI E2E support forums

     AM625: Custom boards cannot boot the system from the SD card 


    AM62A7-Q1: SD card boot issue in customized board 

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Guru**** 226935 points

    Hi Board Designers,

    Inputs related to using MMC0, MMC1 pins as GPIO

    2 platform boards based on AM625. In both designs, they have an external watchdog which is fed by GPIO1_45 which is also an MMC1 pin.

    Observation

    • In the device tree, if the sdhci1 node is explicitly disabled (status = "disabled"), the watchdog node defined in the device tree is picked up correctly and we observe pulsing on the GPIO 1_45
    • In the device tree, if the sdhci1 node is not explicitly disabled i.e. it is not present in the board's device tree, the watchdog node defined in the device tree is picked up correctly but we don't observe pulsing on the GPIO 1_45

    Questions

    • If the sdhci peripheral (say sdhci1) is not used, is it mandatory to explicitly disable it in device tree?
    • Does our linux driver not check for status = "okay" before configuring the MMC1 peripheral?
    • What other peripherals may require the same treatment? I ask so that we are aware and take care of these peripherals already.

    If the sdhci peripheral (say sdhci1) is not used, is it mandatory to explicitly disable it in device tree?

    Yes, the sdhci device tree node should be disabled if any of its pins is used in GPIO mode.

    Does our linux driver not check for status = "okay" before configuring the MMC1 peripheral?

    This is not MMC peripheral specific, rather how device tree is handled in kernel. Please see function of_fdt_device_is_available() linked below, if "status" is not defined, or it is "ok" or "okay", the device tree node is enabled. Any other value of "status" means the device tree node is disabled.

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/of/fdt.c?h=ti-linux-6.1.y#n83

    What other peripherals may require the same treatment? I ask so that we are aware and take care of these peripherals already.

    only sdhci pins.

    Yes, the sdhci device tree node should be disabled if any of its pins is used in GPIO mode.

    Does the MMC driver also configure the IO lines for the MMC peripheral? If yes, why so? Shouldn't the pinmux should be generated separately using the sysconfig tool?

    The pins associated with MMC0 and MMC1 have another higher priority multiplexer in the respective MMCSD module, which controls the signal function connected to these pins. The IOMUX_ENABLE bit in the respective MMCSD register named PHY_CTRL_1_ REG is a global control that selects the signal function for each pin associated with an MMC port. I inserted a snapshot of the register definition below.

    When you enabled MMC in the Linux device tree, the IOMUX_ENABLE bit is being reset to a value of 0. This selects the MMC signal function rather than the GPIO signal function since this bit has a higher priority than the mux mode bits in the PADCONFIG register.

    When you removed MMC from the Linux device tree, this register retains its default value of 1, which allows the PADCONFIG register to select the signal function.

    Regards,

    Sreenivasa