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.
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
Hi Board designers
Thank you for the interest.
The FAQ is being updated.
Please review the FAQ frequently for updates.
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).
Regards,
Sreenivasa
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
(+) 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.
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
Hi Board Designers,
how to make the SD card use only 3.3V?
Regards,
Sreenivasa
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
(+) AM6411: What's the right Spec. for SDIO? - Processors forum - Processors - TI E2E support forums
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 was curious and 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
