Hi TI Experts,
I am referring the collaterals for the below SKs.
SK-AM62B (PROC114A), SK-AM62B-P1 (PROC142A), SK-AM62-LP (PROC124E2A), SK-AM62-SIP (PROC162E1), SK-AM62A-LP (PROC135A), SK-AM62P-LP (PROC164E1.1), TMDS62LEVM (PROC181E1-1)
Is there any Update to be Done on the collaterals to reuse in my custom design.
Hi Board designers,
Here are some recommended updates based on the learnings for performance improvements.
Schematics - Design Value Updates
I2C pullup is recommended irrespective of IO usage for MCU_I2C0 and WKUP_I2C0
AM62x, AM62L, AM62Ax and AM62Px processor families (I2C0 and MCU_I2C0 for AM642/AM243x)
MCU_I2C0 - Pullup and RC added for slew rate control when pulled to 3.3V
WKUP_I2C0 - Pullup and RC added for slew rate control when pulled to 3.3V
Note: The below diagram is for AM64x and the same can be used for AM62x, AM62L, AM62Ax and AM62Px processor families
These I2C interfaces are Open drain type IOs. These I2C interfaces are fail-safe IO terminals.
The rise and fall times of the I2C signals connected to these ports must not exceed a slew rate of 0.08 V/ns (or 8E+7 V/s). This limit is more restrictive than the minimum fall time limits defined in the I2C specification. Therefore, it may be necessary to add additional capacitance to the I2C signals to slow the rise and fall times such that they do not exceed a slew rate of 0.08 V/ns.
Refer below
SOC VMON_VSYS voltage monitor implementation
eMMC attached device supply decap
Add decaps as required to the eMMC memory supply rails
eMMC interface pulls for AM62x, AM62A and AM62D that implements soft (IOs support alternate function) eMMC PHY
eMMC interface pulls for AM64x and AM62Px that implements hard (IOs do not support alternate function) eMMC PHY
Please refer to the errata.
https://www.ti.com/lit/er/sprz574a/sprz574a.pdf
i2458 MMCHS: eMMC HS400 tDCD timing marginal to JEDEC spec
USB VBUS divider
USB interface Provision to Bypass CMC
USB power switch
Use power switch with OC indication. Connect the OC output of the power switch to SoC input
Caution with EPHY 1V and VPP 1.8V LDO
Miniature DQN package used.
Package Outline
PCB pads
There is a likely chance of assembly error due to the LOD outline, pins orientation and the land pattern (pads and pitch)
Regards,
Sreenivasa
Hi Board designers,
To implement UHS-I refer below steps:
The SD card interface pullups have to be connected to the 3.3V_1.8V VDDSHV_SDIO switched supply output from the PMIC or discrete LDO or integrated LDO
Discrete LDO
The SD card needs to be powered using a fixed 3.3V supply.
The 3.3V supply to the SD card needs to be switched through a power switch
Provision to reset the power switch using SOC IOs is recommended
Processor IO supply sequencing
VCC_3V3_SYS LOAD SWITCH
SoC IO supply rails have slew rate requirements specified.
Refer Power Supply Slew Rate Requirement section of the data sheet.
Add a cap 220 pF or higher on the Load switch CT (Switch slew rate control) pin.
An ANDing logic is recommend to reset the SD cars power switch.
The SOC VDDSHV5 supply needs to be connected to the .3V_1.8V VDDSHV_SDIO switched supply output from the PMIC
Integrated LDO
AM64x EVM
AM64x SK
On the SK-AM64B there are 2 options to power the VDDSHV5. Using integrated LDO (AM64x supports integrated LDO) or use PMIC LDO output.
The SK is configured to use the integrated LDO and the PMIC LDO output is not connected.
It is OK to connect VDDSHV5 supply to any of the 2 supply sources.
i'm refering the data sheet（www.ti.com/.../am6421.pdf） chapter5.4 Pin Connectivity Requirements.
There is no information for MMC1 at there. How each MMC1 pins should be treated when MMC1 is unused?
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.
Start-up issue due to SD card power switch
Note:
It is not possible for AM64x or AM62Px because SD Cards begin operation at 3.3V and the MMC0 port on these devices is limited to 1.8V.
We do not expect SD Cards to be connected to the MMC0 port of AM62x, AM62Ax, AM62Dx, or AM62Lx. SD Cards should be connected to MMC1 or MMC2 of these devices. However, we do allow SDIO embedded devices to be connected to the MMC0 port of these devices.
AM6411 & SDIO Impedance recommendation
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.
Regards,
Sreenivasa
Hi Board designers,
Implementation of ANDing logic for attached device reset
eMMC
EPHY
Regards,
Sreenivasa
Hi Board designers,
Connection of nRSTOUT of PMIC directly to MCU_PORz
We define a minimum slew rate in the SOC datasheet for inputs and this creates a maximum rise time requirement. The rise/fall time for the reset signal must be less than 1000ns, not greater than 1000ns. To ensure your design meets this requirement, you may need to use a buffer between the PMIC and SOC or select a pull-up resistor value that is strong enough to charge your PCB parasitic capacitance and the SOC input capacitance in less than 1000ns. A rise significantly faster than 1000ns is preferred to minimize the potential of noise coupling to the reset signal.
There can be long-term reliability issues associate with the input buffer if the applied signal spends too much time in the voltage region between VIHSS and VILSS. The maximum transition time allowed is 1000ns. I recommend driving the reset input with a push-pull buffer that produces a signal transition rate that is faster than 5ns to eliminate the risk of noise coupling into the signal as it transitions through the input buffer switching threshold
I forgot to mention another important point about the MCU_PORz input slew rate. It is very easy for noise to couple on slow rising signals such that it creates non-monotonic transitions. Your MCU_PORz reset source needs to be monotonic to prevent the chance of creating glitches on internal reset as it transitions through the input buffer switching threshold. A faster slew rate on the MCU_PORz will increase your system noise immunity. The min slew rate defined in the AM62Ax datasheet is acceptable to the AM62A device but may not be acceptable for your system noise immunity requirements.
We get request from schematic review team to add a buffer between PMIC TPS65224 RSTOUT pin and SOC MCU_PORZ pin. I think the reason is that the SOC MCU_PORZ will require the rising edge and falling edge
The MCU_PORz is the main cold reset input for the SOC.
The PMIC nRSTOUT is a open drain slow ramp output from the PMIC.
When a slow ramp reset input is applies to the MCU_PORz there are likely chances that the internal reset circuit could glitch.
A discrete push pull output buffer is recommended to minimze the slew.
We do not have a spec for the MCU_PORz. The recommendation is faster the better. (<10ns)
(+) [FAQ] AM623: MCU_PORz input slew rate - Processors forum - Processors - TI E2E support forums
Implementation of MCU_PORz discrete buffer
Regards,
Sreenivasa
Hi Board designers,
PMIC capacitor and feedback recommendations
PMIC - feed back and jumper or 0R provisioning
Regards,
Sreenivasa
Hi Board designers,
OSPI pullup, pulldown and series resistor implementation.
AM62L OSPI0 interface connected to x2 memory devices
Regards,
Sreenivasa
Hi Board designers,
Ethernet interface (MAC)
Ethernet PHY EPHY reset recommendations
Option 1
Option 2
EPHY clocking
AM64x
AM62x
(28) SK-AM64: clock sync - Processors forum - Processors - TI E2E support forums
we are currently evaluating AM64xx on the SK-AM64: is there an easy way to use the 25MHz system clock via a CLKOUT pin for external peripherals
to be brought out and used without changing various PLL clocks / multiplexers and dividers via registers?
Basically to have 3x GPIO as CLOKOUT sync'd ( I'm looking for a solution to feed up to 3x external Ethernet PHYs with 25MHz ).
OBSCLK0 is the only AM64x clock signal that is not generated from one of the internal PLLs. However, this clock output is only multiplexed to one pin. Software would need to configure the pin multiplexer to select this function and there is no way to prevent the attached device from seeing a short clock since the mux mode change is not synchronized to the clock output. This clock output is only provided as an observation clock.
Your customer should consider the approach implemented on the AM64x EVM, where an external LVCMOS clock source is used as the system reference clock and distributed to multiple devices. Note: This approach requires a single input to multiple output buffer so each device receives its clock from a dedicated clock output with point to point connectivity. Any attempt to clock multiple devices from a common clock output is likely to be problematic.
Regards,
Sreenivasa
Hi Board designers,
AM62L RTC only Discrete LDO implementation
Regards,
Sreenivasa
Hi Board designers,
Refer below for DDR4 clock termination.
I have a question from my customer for DDR CLK termination specfication.
According to SK-AM62 schematics (PROC114E3_SCH.pdf), page#16.
DDR_CLKP/N are terminated by resisters and capacitor.
Do you have DDR termination specification? How these resisters and capacitor values are defined?
This is actually taken from the DDR4 recommendation from Micron, in their appnote TN-40-40. Here is the quote from the appnote:
Hi Board Designers,
Refer below inputs regarding SD card power switch reset logic implementation:
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 understanding, 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
Hi Board Designers,
Refer below inputs regarding SD card SDCD pin
AM62A3-Q1: SDCD Interface
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.
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)
The IP registers and associated bitfield definitions are not necessarily required to exactly reflect the logical truth table defined by the physical layer specification.
AM623: uSD Card Detection Without Card Detect
Ok but since the uSD Card Carrier does not have provision for Card Detect switch, the customer would hard wire it to 0. Then what happens to my 2 use cases? especially if no uSD is present?
the ROM will attempt to boot if the card detect is sampled active low. If it doesn't find an image (which it won't if no card is detected), it will timeout and move on to the secondary boot source.
The ROM code team has confirmed they check the card detect input and will not boot from the SD Card if a card is not detected. Therefore, your product needs to use a SD Card connector with a card detect switch to properly indicate when a card is inserted in the connector.
This power switch, along with the reset logic, and the host IO power supply circuit is required to support UHS-I SD Cards which begins communications using 3.3V signal levels and later change to 1.8V signal levels when changing to one of the faster data transfer speeds. Cycling power to the SD Card is the only way to put it back into 3.3V mode since SD Cards do not have a reset pin. The host IO power supply must power off/on and change voltage at the same time as the SD Card. These circuits and the software driver operating the signals sourcing these circuits ensure both devices are off, or on and operating at the same IO voltage at the same time.
We have a custom board based on a TDA4x SoC and have trouble booting from the SD card.
We noticed the MMC1_SDCD pin (card detect) but our MicroSD socket doesn't have this functionality (card detect switch).
Is it possible to skip SDCD checking from TDA4x side?
Is there a way to set BOOTMODE pins differently to change this MMC1_SDCD impact?
If booting from MMC1, the SDCD pin is required to be low to indicated card is available. The pin can be tied low or connected to card detect from card cage. This is required from MMC1 boot process with no bypass mechanism.
Regards,
Sreenivasa
