[FAQ] AM625 / AM623 / AM620-Q1 / AM62Ax / AM62Px / AM62D-Q1 / AM62L / AM64x / AM243x Design Recommendations / Custom board hardware design - Queries related to GPIO

Hi Board Designers, 

Refer below inputs:

AM62L
Supported IO supply for IO groups are listed below:
• VDDSHV0 – Dual-voltage IO supply for GPMC0 IO group (Fixed), DPI, bootmode, GPMC0
• VDDSHV1 – Dual-voltage IO supply for General interface IO group (Fixed)
• VDDSHV2 – Dual-voltage IO supply for MMC0 IO group (Fixed or Dynamic supply switching)
• VDDSHV3 – Dual-voltage IO supply for MMC1 IO group (Fixed or Dynamic supply switching)
• VDDSHV4 – Dual-voltage IO supply for MMC2 IO group (Fixed or Dynamic supply switching)

VDDS0 – Fixed-voltage supply for GENERAL0 IO group (RGMII1, RGMII2 IO groups)
VDDS1 – Fixed-voltage supply for GENERAL0_1 IO group (includes OSPI0 IO group)
VDDS_RTC – Fixed-voltage supply for LFOSC0 and RTC IO group
VDDS_WKUP – Fixed-voltage supply for WKUP IO group

AM62x
Supported IO supply for IO groups are listed below:
• VDDSHV0 – Dual-voltage IO supply for Main reset and General interface IO group (Fixed)
• VDDSHV1 – Dual-voltage IO supply for OSPI0 IO group (Fixed)
• VDDSHV2 – Dual-voltage IO supply for RGMII1, RGMII2 IO group (Fixed)
• VDDSHV3 – Dual-voltage IO supply for GPMC0 IO group (Fixed), DPI, bootmode, trace
• VDDSHV4 – Dual-voltage IO supply for MMC0 IO group (Fixed or Dynamic supply switching)
• VDDSHV5 – Dual-voltage IO supply for MMC1 IO group (Fixed or Dynamic supply switching)
• VDDSHV6 – Dual-voltage IO supply for MMC2 IO group (Fixed or Dynamic supply switching)
• VDDSHV_MCU – Dual-voltage IO supply for WKUP_MCU IO group (Fixed)
• VDDSHV_CANUART – Dual-voltage IO supply for CANUART IO group (Fixed)

AM62Ax
Supported IO supply for IO groups are listed below:
• VDDSHV0 – Dual-voltage IO supply for Main reset and General interface IO group (Fixed)
• VDDSHV1 – Dual-voltage IO supply for OSPI0 IO group (Fixed)
• VDDSHV2 – Dual-voltage IO supply for RGMII1, RGMII2 IO group (Fixed)
• VDDSHV3 – Dual-voltage IO supply for GPMC0 IO group (Fixed),DPI, bootmode, trace
• VDDSHV4 – Dual-voltage IO supply for MMC0 IO group (Fixed or Dynamic supply switching)
• VDDSHV5 – Dual-voltage IO supply for MMC1 IO group (Fixed or Dynamic supply switching)
• VDDSHV6 – Dual-voltage IO supply for MMC2 IO group (Fixed or Dynamic supply switching)
• VDDSHV_MCU – Dual-voltage IO supply for WKUP_MCU IO group (Fixed)
• VDDSHV_CANUART – Dual-voltage IO supply for CANUART IO group (Fixed)

AM62P
Supported IO supply for IO groups are listed below:
• VDDSHV0 – Dual-voltage IO supply for Main reset and General interface IO group (Fixed)
• VDDSHV1 – Dual-voltage IO supply for OSPI0 IO group (Fixed)
• VDDSHV2 – Dual-voltage IO supply for RGMII1, RGMII2 IO group (Fixed)
• VDDSHV3 – Dual-voltage IO supply for GPMC0 IO group (Fixed), DPI, bootmode, trace
• VDDSHV5 – Dual-voltage IO supply for MMC1 IO group (Fixed or Dynamic supply switching)
• VDDSHV6 – Dual-voltage IO supply for MMC2 IO group (Fixed or Dynamic supply switching)
• VDDSHV_MCU – Dual-voltage IO supply for WKUP_MCU IO group (Fixed)
• VDDSHV_CANUART – Dual-voltage IO supply for CANUART IO group (Fixed)

AM64x
Supported IO supply for IO groups are listed below:
• VDDSHV0 – Dual-voltage IO supply for Main reset and General interface IO group (Fixed)
• VDDSHV1 – Dual-voltage IO supply for CPSW3G, PRG0 IO group (Fixed)
• VDDSHV2 – Dual-voltage IO supply for PRG1 IO group (Fixed)
• VDDSHV3 – Dual-voltage IO supply for GPMC0 IO group (Fixed)
• VDDSHV4 – Dual-voltage IO supply for OSPI0 IO group (Fixed)
• VDDSHV5 – Dual-voltage IO supply for MMC1 IO group (Fixed or Dynamic supply switching)
• VDDSHV_MCU – Dual-voltage IO supply for MCU General IO group (Fixed)

Available GPIO instances and interrupt  capability

GPIO Use Cases and Implementation With the AM6x Family of Sitara MPU Devices

https://www.ti.com/lit/ab/spradk0/spradk0.pdf

AM64x/AM243x
Signal Descriptions
GPIO
MAIN Domain Instances
GPIO0 Signal Descriptions

GPIO0_0 ... GPIO0_86
GPIO1 Signal Descriptions

GPIO1_0...GPIO1_79
MCU Domain Instances
MCU_GPIO0 Signal Descriptions

MCU_GPIO0_0...MCU_GPIO0_22

General Purpose Input/Output Interface (GPIO)
Integrated in MAIN domain: Two General Purpose Input/Output (GPIO) modules that provide dedicated general purpose
pins that can be configured as either inputs or outputs. The GPIO modules main features include:
• Support of 9 banks x 16 GPIO pins
• Support of up to 9 banks of interrupt capable GPIOs
• Interrupts can be triggered by rising and/or falling edge, specified for each interrupt capable GPIO pin
• Set/clear functionality per individual GPIO pin

Note:

1. GPIOMUX_INTRTR_IN_[198:0] - Any of the 0-198 GPIOs can be routed to GPIOMUX_INTRTR0

2. GPIOMUX_INTRTR0 supports MAIN_GPIOMUX_INTROUTER0_OUTP_[53:0] outputs

3. MAIN_GPIOMUX_INTROUTER0_OUTP_[53:0] is split as MAIN_GPIOMUX_INTROUTER0_OUTP_[15:0] and  routed to R5FSS0_CORE0/1 

Similarly interrupts are routed to different cores and PRU

AM62x

GPIO
MAIN Domain
GPIO0 Signal Descriptions

GPIO0_0...GPIO0_91
GPIO1 Signal Descriptions

GPIO1_0...GPIO1_51
MCU Domain
MCU_GPIO0 Signal Descriptions

MCU_GPIO0_0...MCU_GPIO0_23

References for interrupt 

4.7 General Connectivity
4.7.1 General Purpose Input/Output (GPIO)
This section contains the integration details for the GPIO modules on this device. For Further information, see
the General Purpose Interface section of the Peripherals chapter

10.1.5 GPIO Interrupt Handling
There are three GPIO modules in the device, which could generate almost 200 interrupts. Those GPIO interrupt
outputs are routed to the GPIO interrupt router first before they are routed to the final interrupt destination. The
GPIO interrupt router allows each output to select each GPIO interrupt independently.

Table 10-9. GPIO_mux_introuter Connection

Bank and individual registers

12.2.1 General-Purpose Interface (GPIO)
This chapter describes the General-Purpose Input/Output (GPIO) for the device.
12.2.1.1 GPIO Overview
The General-Purpose Input/Output (GPIO) peripheral provides dedicated general-purpose pins that can be
configured as either inputs or outputs. When configured as an output, the user can write to an internal register to
control the state driven on the output pin. When configured as an input, user can obtain the state of the input by
reading the state of an internal register.
In addition, the GPIO peripheral can produce host CPU interrupts and DMA synchronization events in different
interrupt/event generation modes.
The device has one or more instances of GPIO modules. The GPIO pins are grouped into banks (16 pins
per bank and 9 banks per module), which means that each GPIO module provides up to 144 dedicated
general-purpose pins with input and output capabilities; thus, the general-purpose interface supports up to 432
(3 instances × (9 banks × 16 pins)) pins. Since MCU_GPIO0_[23:143], GPIO0_[87:143], and GPIO1_[88:143]
are reserved in this device, general purpose interface supports up to 198 pins.
Signal Descriptions

12.2.1.4.4 GPIO Interrupt Connectivity
Because this device muxes GPIO signals with other functional signals, the availability of any particular GPIO and
hence the usability of its associated interrupt will change based on the use case pin muxing. The large number
of possible GPIO interrupt sources makes it impractical to route all interrupt events to each processing element.
Since most applications do not typically require a large number of GPIO interrupts, the interrupt uncertainty
is resolved by mapping all GPIO interrupts to a series of event muxes implemented using Interrupt Router
(IntRouter) modules. These muxes allow any one of the available GPIO interrupts to be selected and passed
on as an event to the various processor interrupt controllers and DMA controllers. Event selection is controlled
through associated registers within each IntRouter.
The GPIO bank interrupts already represent a consolidation of the 16 GPIO interrupts associated with each bank
and are routed directly to various interrupt controllers rather than through the GPIO IntRouters.
One of the GPIO pins has a potential use case as an Arm reset input and should therefore be routed as highest
priority interrupt in the GIC and mapped to nFIQ in software.

AM62Ax/AM62Dx
Signal Descriptions
GPIO
MAIN Domain Instances
GPIO0 Signal Descriptions

GPIO0_0...GPIO0_91
GPIO1 Signal Descriptions

GPIO1_0...GPIO1_51
MCU Domain Instances
MCU_GPIO0 Signal Descriptions

MCU_GPIO0_0...MCU_GPIO0_23

AM62D-Q1

4.8 General Connectivity
4.8.1 General Purpose Input/Output (GPIO)
This section contains the integration details for the GPIO modules on this device. For Further information, see
the General Purpose Interface section of the Peripherals chapter

10.1.3 GPIO Interrupt Handling
There are three GPIO modules in the device, which could generate almost 200 interrupts. Those GPIO interrupt
outputs are routed to the GPIO interrupt router first before they are routed to the final interrupt destination. The
GPIO interrupt router allows each output to select each GPIO interrupt independently.

The two GPIO modules in the Main domain use one GPIO interrupt router while the GPIO
module in MCU domain has its own dedicated GPIO router. See Figure 10-7. See also
MAIN_GPIOMUX_INTROUTER0_INTERRUPT_MAP and MCU_GPIOMUX_INTROUTER0_INTERRUPT_MAP

10.5.1.11 MAIN_GPIOMUX_INTROUTER0 Interrupts (AM62D)

12.2.1 General-Purpose Interface (GPIO)
This chapter describes the General-Purpose Input/Output (GPIO) for the device.
12.2.1.1 GPIO Overview
The General-Purpose Input/Output (GPIO) peripheral provides dedicated general-purpose pins that can be
configured as either inputs or outputs. When configured as an output, the user can write to an internal register to
control the state driven on the output pin. When configured as an input, user can obtain the state of the input by
reading the state of an internal register.
In addition, the GPIO peripheral can produce host CPU interrupts and DMA synchronization events in different
interrupt/event generation modes.
The device has one or more instances of GPIO modules. The GPIO pins are grouped into banks (16 pins
per bank and 9 banks per module), which means that each GPIO module provides up to 144 dedicated
general-purpose pins with input and output capabilities; thus, the general-purpose interface supports up to 432
(3 instances × (9 banks × 16 pins)) pins. Not all GPIO pins are pinned out. See General Purpose Input/Output
(GPIO) in the Module Integration section for more information.

12.2.1.4.3 Interrupt and Event Generation

12.2.1.4.3 Interrupt and Event Generation
Each GPIO pin (GPj) can be configured to generate a host CPU interrupt (GPINTj) or a synchronization event
to the DMA (GPINTj). Configuration is on per-bank basis. Each bit of the BINT_EN parameter dictates YES/NO
option for each bank. Bit 0 controls bank 0, bit 1 controls bank 1, and so on.
The interrupt and DMA event can be generated on the rising-edge, falling-edge, or on both edges of the GPIO
signal. The edge detection logic is synchronized to the GPIO peripheral clock.
The direction of the GPIO pin does not need to be input when using the pin to generate the interrupt or DMA
event. When the GPIO pin is configured as input, transitions on the pin trigger interrupts or DMA events. When
the GPIO pin is configured as output, software can toggle the GPIO output register to change the pin state and in
turn trigger the interrupt or DMA event.
Note that the direction of the pin need not be input for interrupt generation to work. When the GPINT pin
is configured as input, transitions on the pin trigger interrupts. When the GPINT pin is configured as output,
firmware can toggle the GPIO output register to change the pin state, and in turn trigger interrupts.
Each interrupt output of GPINT signal are available at the module boundary. Each group of 16 GPINT signals
also has their masked interrupt outputs ORed together to generate a per bank interrupt, available at the module
boundary. The idea is to either connect individual interrupts or per bank interrupts to the system interrupt
controller.
12.2.1.4.3.1 Interrupt Enable (per Bank)
The GPIO_BINTEN register provides interrupt enable/disable feature for each bank of 16 GPINT signals.

12.2.1.4.3.2 Trigger Configuration (per Bit)
Two internal registers, RIS_TRIG and FAL_TRIG, specify which edge of the GPj signal generates an interrupt
or DMA event. Each bit in these two registers corresponds to a GPj pin.

12.2.1.4.4 GPIO Interrupt Connectivity

Because this device muxes GPIO signals with other functional signals, the availability of any particular GPIO and
hence the usability of its associated interrupt will change based on the use case pin muxing. The large number
of possible GPIO interrupt sources makes it impractical to route all interrupt events to each processing element.
Since most applications do not typically require a large number of GPIO interrupts, the interrupt uncertainty
is resolved by mapping all GPIO interrupts to a series of event muxes implemented using Interrupt Router
(IntRouter) modules. These muxes allow any one of the available GPIO interrupts to be selected and passed
on as an event to the various processor interrupt controllers and DMA controllers. Event selection is controlled
through associated registers within each IntRouter.
The GPIO bank interrupts already represent a consolidation of the 16 GPIO interrupts associated with each bank
and are routed directly to various interrupt controllers rather than through the GPIO IntRouters.
One of the GPIO pins has a potential use case as an Arm reset input and should therefore be routed as highest
priority interrupt in the GIC and mapped to nFIQ in software.

AM62Px
Signal Descriptions
GPIO
MAIN Domain Instances
GPIO0 Signal Descriptions

GPIO0_0...GPIO0_91
GPIO1 Signal Descriptions

GPIO1_0...GPIO1_51
MCU Domain Instances
MCU_GPIO0 Signal Descriptions

MCU_GPIO0_0...MCU_GPIO0_23

(+) AM62A7-Q1: Shared GPIO Bank Access Between (Main) and (MCU) Cores Part Number: - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Is it a supported use case to have two different cores ( Main domain and the MCU domain) concurrently access and control different pins within the same GPIO bank of the MAIN_GPIO0 module?

Specific Scenario:

• GPIO0_45 (Bank 2) needs to be controlled by the MCU domain  for a real-time task.

• GPIO0_46 (Bank 2) needs to be controlled by the Main domain  running Linux.

While I plan to use SET_DATA and CLR_DATA registers to avoid race conditions, does the hardware provide full isolation within a single bank register for simultaneous access?

Set and Clear should be fine. Linux uses bank level interrupt so, if they need to use interrupts, the above use case can be problematic.

AM62L
Signal Descriptions
GPIO
MAIN Domain Instances
GPIO0 Signal Descriptions

GPIO0_0...GPIO0_99
WKUP Domain
WKUP_GPIO0 Signal Descriptions

WKUP_GPIO0_0...WKUP_GPIO0_6

Related Queries

LVCMOS VIH/VIL

The datasheet states output voltage level of LVCMOS as follows.

 1.8V mode:

VOL     0.45V max.                 @ IOL=3mA

VOH     VDD-0.45V min.          @ IOH=3mA

3.3V mode:

VOL     0.4V max.                   @ IOL=5mA

VOH     2.4V min.                   @ IOH=9mA

AM62P LVCMOS connects to a CMOS buffer fewer current ,e.g. 100uA, would be expected, in general.

Is there any definition by small current available in order to have lower VOL and higher VOH ?

If yes, it might contribute to flexible device selection.

Answers

We recommend customer to use the IBIS model and perform simulation for any current lower than the data sheet recommended value to derive the voltage level.

The customer will need to use the IBIS model of the output buffer in a simulation with the reduced load to determine the VOL and VOH values for their operating condition.

What I am asking is if TI can provide guaranteed VOL and VOH with lower current than datasheet value.

There are no plans to provide any other data points in the datasheet. It is not possible for TI to know the DC load applied to each output buffer of every customer's AM62Px system design. Therefore, we only define 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.

(+) [FAQ] AM6442: AM6442 LVCMOS Buffer Type - Processors forum - Processors - TI E2E support forums

The Electrical Characteristics tables defines capabilities of a specific IO cell. It does not define a how the IO is configured to operate. You need to reference the Pin Attributes table to understand how the IO associated with each pin is configured to operate. For example, the AM64x RESETSTATz signal function is implemented such that it is "Off / Low / Off" while MCU_PORz is asserted and "Off / SS / Off" after MCU_PORz has been de-asserted. This indicates the input buffer associated with the RESETSTATz pin is turned off during and after reset. The output buffer associated with the RESETSTATz pin is enabled during and after reset, where the output is actively driven low during reset and controlled by the reset subsystem after reset. The internal pull resistors associated with the RESETSTATz pin are turned off during and after reset.

In summary the RESETSTATz pin is an always enabled output only pin, where Vol, Voh, Iol, and Ioh are the only parameters defined in the LVCMOS Electrical Characteristics table that applies to the LVCMOS IO that is being used to implement the RESETSTATz pin.

AM62P pin status during reset

This is described in the "BALL STATE DURING RESET RX/TX/PULL:" and "BALL STATE AFTER RESET RX/TX/PULL:" at the beginning of the Pin Attributes section.  The first value represents the state of input buffer, the second value represents the state of the output buffer, and the third value represents the state of internal

The datasheet defines the value of "Off" as shown below:

• TX (Output buffer)
– Off: The output buffer is disabled.
– Low: The output buffer is enabled and drives VOL.

So yes, the pin will be HI-Z when the output buffer is disabled.

From the AM62Px device perspective, you do not need to do anything to these pins as long as they remain in this state. There is no issue until software enables the input buffer. However, you must never allow any AM62Px pin which has its input buffer enabled to float, to a mid-supply potential. This can damage the input buffer when it spends too much time in the mid-supply region. Pins which have their input buffer enabled, should have a steady-state potential that is less than VILSS or greater than VIHSS, and toggle quickly between valid logic states. 

Note: There are a few AM62Px pins which have their input buffer enabled by default. For example, the boot mode inputs. These pins require external pulls to hold them in a valid logic state as soon as power is applied.

Note: Devices attached to the AM62Px pins may require external pulls to hold their pins in a valid logic state. This is unique to each system design, so the system designer will need to evaluate the correct implementation for their system.

Unused pin Default State

The default configuration disables both the receiver and the transmitter in the IO

The input buffer is turned off, the output buffer is disabled, and internal pulls are turned off for most of the device pins by default. This is done because most of these pins have multiple signal functions, and we never know how they are going to be used. The ESD circuits are still attached to the pin, but our ESD circuits are only design to protect the device before and during PCB assembly. ESD performance is only based on human body models and charged device models that represent a typical person or machine handling the device when it is being installed on the PCB. The ESD circuits were not designed to protect the pins from system level ESD events after being installed on the PCB.  Your system design must protect the device pins from any Electrical Over-Stress (EOS) event after it has been installed on the PCB.  Connecting unterminated signal traces to these pins would not be a good design practice since there is nothing to limit the voltage potential of these pins.

Is there a recommendation for AM62A3 device pin configuration connected to unterminated traces?

These questions have dependencies on your system design.

We are not able to make any specific recommendation because we do not know your intentions for the unterminated traces. You need to make sure the potential applied to AM62Ax pins remain within the limits defined by the device datasheet.

For example, the potential applied to a device pin must never exceed the Steady-state max voltage level defined in the Absolute Maximum Ratings table and the potential applied to any enabled input buffer must remain below the VILSS or above the VIHSS levels defined for that IO type unless the signal is changing logic levels while not violating the minimum slew rate limit for that IO type.

You will need to determine the potential that can be produced when energy from electrical noise or crosstalk couples into these unterminated traces and apply the appropriate termination to ensure the above. The answer to this question will be specific to you PCB design and the operating environment of your system.

General guidelines are listed below:

Connection of Unused Processor Open-Drain IOs
MCU_I2C0 and WKUP_I2C0 for AM62x, AM62A, AM62L and MCU_I2C0 and I2C0 for AM64x and AM243x
Allowing enabled input buffers to float may damage the input buffer. Therefore, your system design must never allow any of the AM243x digital pins to float to a mid-supply potential while the associated input buffer is enabled.
The I2C0 and MCU_I2C0 pins require an external pull-up or external pull-down to be connected because the input buffers associated with these pins are enabled by default as soon as power is applied to the device. Without external pulls, they would be floating until software has time to boot and disable the input buffers associated with these pins.
It is possible to connect pins implemented with the "I2C OD FS" buffer type directly to ground since it is not possible for this to cause any contention for the output becasue it is not able to drive high.

Connection of unused Processor LVCMOS or SDIO IOs
Most of the AM243x digital pins power-up with their inputs disabled by default. You do not need to connect external pulls to pins that do not have any signal trace connected as long as the associated input buffers are disabled by default and never enabled by software.
When traces are connected to IOs, external pull provides a leakage path on the very high-impedance unterminated signal trace before software is able to turn on the internal pull. Without a leakage path, the unterminated signal trace can act like an antenna and develop a potential when exposed to strong electric fields or noise sources and reach a potential that is larger than the Recommended Operating Condition (ROC) of the AM243x pin. The external pull is being recommended to prevent a possible Electrical Over-Stress (EOS) condition occurring on the AM243x pin. Using the internal pull to provide a leakage path exposes the pin to this concern while waiting for software to turn on the internal pull.
This is not a concern when an unused pin doesn't have any signal trace connected.

The pin is configured as GPIO and it's actually used as GPIO, and it's connected to external IC. Internal PULL will be enabled by SW after boot. At this case, the signal will be controlled by SoC or external IC, therefore I though that the external pulls to pins are not required.

The external pull provides a leakage path on the very high-impedance unterminated signal trace before software is able to turn on the internal pull. Without a leakage path, the unterminated signal trace can act like an antenna and develop a potential when exposed to strong electric fields or noise sources and reach a potential that is larger than the Recommended Operating Condition (ROC) of the AM243x pin. The external pull is being recommended to prevent a possible Electrical Over-Stress (EOS) condition occurring on the AM243x pin. Using the internal pull to provide a leakage path exposes the pin to this concern while waiting for software to turn on the internal pull.

This is not a concern when an unused pin doesn't have any signal trace connected.

Note:

The IO buffers associated with most of the pins are turned off by default. When I say turned off, the receiver is turned off, the transmitter is turned off, and the internal pulls are turned off. TI doesn't know what will be connected to these pins, so the IOs are turned off to prevent any contention with an attached device.
It doesn't matter which signal function is selected. The customer needs to protect the IO before software configures the pin.
The input buffers associated with the AM243x device must never be allowed to float to a mid-supply potential while the receiver is enabled. There is no concern with a AM243x input floating while the receiver is turned off, as long as the potential applied remains within the ROC limits. However, that may not be the case for any attached device. Your system design may need external pulls to hold a signal in a valid logic state for the input buffer of an attached device even when the AM243x is protected with its receiver turned off. The AM243x pins must remain within the ROC limits, even when the receiver is turned off.
In some cases, an attached device may be driving the AM243x pin or have an internal pull turned on by default which will hold the signal in a valid logic state. If so, an external pull may not be required. However, be careful and confirm the value of the pull is able to over-drive the combined worst case signal leakage such that the signal remains in a valid logic state (above VIHSS or below VILSS) when not actively driven.
Any unterminated signal trace connected to a AM243x pin needs to be protected with an external pull before software is able to turn on the internal pull. An unterminated signal trace may be a signal trace going to a connector where nothing is connected or it may be a signal trace that connects to an input of an attached device that doesn't have an internal pull turned on by default. We do not want any high-impedance unterminated signal trace connected the AM243x since this can lead to an Electrical Over-Stress (EOS) conditions when exposed to strong electric fields or noise sources.
The customer needs to check every connection to AM243x to see if their use case exposes the device to this concern. If so, it can be resolved by adding an external pull.

AM62A3: Unused pin Default State
The default configuration disables both the receiver and the transmitter in the IO. Let me loop in a colleague on the specifics of the IO
As mentioned, the input buffer is turned off, the output buffer is disabled, and internal pulls are turned off for most of the device pins by default. This is done because most of these pins have multiple signal functions, and we never know how they are going to be used. The ESD circuits are still attached to the pin, but our ESD circuits are only design to protect the device before and during PCB assembly. ESD performance is only based on human body models and charged device models that represent a typical person or machine handling the device when it is being installed on the PCB. The ESD circuits were not designed to protect the pins from system level ESD events after being installed on the PCB. Your system design must protect the device pins from any Electrical Over-Stress (EOS) event after it has been installed on the PCB. Connecting unterminated signal traces to these pins would not be a good design practice since there is nothing to limit the voltage potential of these pins.

What is TI's recommendation for AM62A3 device pin. configuration connected to unterminated traces?
If we are able to terminate some traces (resistor to GND or VDD), what is TI's recommendation for device pins on unused terminated traces?
These questions have dependencies on your system design. We are not able to make any specific recommendation because we do not know your intentions for the unterminated traces. You need to make sure the potential applied to AM62Ax pins remain within the limits defined by the device datasheet.
For example, the potential applied to a device pin must never exceed the Steady-state max voltage level defined in the Absolute Maximum Ratings table and the potential applied to any enabled input buffer must remain below the VILSS or above the VIHSS levels defined for that IO type unless the signal is changing logic levels while not violating the minimum slew rate limit for that IO type.
You will need to determine the potential that can be produced when energy from electrical noise or crosstalk couples into these unterminated traces and apply the appropriate termination to ensure the above. The answer to this question will be specific to you PCB design and the operating environment of your system.
Understood. We will terminate the unused device pins with external resistors to GND or VDD as appropriate.

Specification of output voltage of LVCMOS

The customer is trying to use the LVCMOS output pin with 1.8VMODE, but the maximum vol value is 0.45V (IOL = 3mA), which is a high specified value, and the design does not work if the electrical characteristics are interpreted as it is.

Assuming that vol is specified by the on resistance of the NMOS of LVCMOS, is it correct to assume that if an external PD is prepared, the IOL is 0 mA, so the actual vol is 0 V (because the voltage drop at the on resistance of the NMOS does not occur)?

The max limit defined for VOL is valid as long as the IOL is less than 3mA, and the min limit defined for VIH is valid as long as the IOH is less than 3mA.

The datasheet is saying the output buffer is able to sink current up to the min IOL current of 3mA and the low-level output voltage will remain less than the max value of 0.45V defined for VOL, and the output buffer is able to source current up to the min IOH current of 3mA and the high-level output voltage will remain greater than the min value of (VDD - 0.45V) defined for VOH.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1534012/am6422-connecting-unused-processor-ios-or-power-pins-or-nc-pins 

AM6422: Connecting unused processor IOs or power pins or NC pins

How does a circuit act as a LVCMOS buffer?

AM62P treatment on unused pins

Most LVCMOS pins will be turned off by default, so these pins can be left unconnected if software never enables the input buffer associated with a pin. A pin which has its input buffer enabled must never be allowed to float to a mid-supply voltage greater than VILSS and less than VIHSS. Input buffers may be damaged if it spends too much in the mid-supply region. 

Voltage on an unconnected AM62Dx pin is possible. The voltage observed on the pin is the result of leakage paths in the IO buffer, where the leakage can be as much as 10uA to either VSS or VDDSHV. This is normal as long as the leakage is not greater than 10uA. The resulting mid-supply voltage is not a problem for the AM62Dx device as long as the receiver (input buffer) in the IO buffer remains off. However, the pin must be driven or pulled to a valid logic level anytime the receiver is turned on. Never allow the input of an enabled input buffer in the AM62Dx device to float.

Note: We recommend external pulls to be used on any signal that connects AM62Dx to the input of another device. The external pull is needed to hold the signal in a valid logic state until software turns on the associated AM62Dx IO buffer such that it drives the signal to a valid logic state.

About VILSS and VIHSS

The VIL and VIH parameters are the traditional DC logic level thresholds, where the logic state will be low when the applied voltage less than or equal to VIL, high when greater than or equal to VIH, and undefined when greater then VIL and less than VIH.

The VIL and VIH parameters are the traditional DC logic level thresholds, where the logic state will be low when the applied voltage less than or equal to VIL, high when greater than or equal to VIH, and undefined when greater then VIL and less than VIH.

The VILSS and VIHSS parameters are associated with device reliability, where any steady-state potential needs to remain below VILSS or above VIHSS to minimize the input buffers shoot-through current. The input buffer has a limited amount of time it can spend in the voltage region between VILSS and VIHSS without long-term reliability concerns. This is why the Electrical Characteristics tables define a minimum slew rate parameter that constrains the amount of time an input is allowed to be in this region. The amount of time a signal can be within this region is a function of toggle frequency, with a maximum upper bound of 1000ns for rise/fall times.

The VILSS and VIHSS parameters are associated with device reliability, where any steady-state potential needs to remain below VILSS or above VIHSS to minimize the input buffers shoot-through current. The input buffer has a limited amount of time it can spend in the voltage region between VILSS and VIHSS without long-term reliability concerns. This is why the Electrical Characteristics tables define a minimum slew rate parameter that constrains the amount of time an input is allowed to be in this region. The amount of time a signal can be within this region is a function of toggle frequency, with a maximum upper bound of 1000ns for rise/fall times.

LVCMOS IO configuration 

Example: OSPI0_LBCLKO

Most of the AM62Px IOs default to mux mode 7, which selects the GPIO signal function. The IO cells associated with these pins default to an off state, where the input buffer is turned off, the output buffer is turned off, and the internal pulls are turned off. It is possible to allow these pins to float as long as software never turns on the input buffer with the RXACTIVE bit in the respective PADCONFIG register. You should never allow any of these pins to float to a mid-supply level between VILSS and VIHSS while the input buffer is enabled because exposure to this condition could damage the input buffer.  We limit the time allowed in this mid-supply region when the input is enabled by defining a minimum input slew rate for each buffer type in the Electrical Characteristics section of the datasheet.

The IO associated with the OSPI0_LBCLKO pin is internally connected to the GPIO module when MUXMODE is 7. However, the IO cell will be turned off by default and will remain off until software turns it on.

Software can enable the input buffer, enable the output buffer, or enable the internal pulls independently via the PADCONFIG register. So, the state of the pin depends on how software configures the PADCONFIG register. Once the PADCONFIG register is configured, it will depend on how the GPIO0 module is configured when MUXMODE = 7, or how the UART5 module is configured when MUXMODE = 5, or how the OSPI0 module is configured when MUXMODE = 1.

Slew Rate

The min slew rate defined in the electrical characteristics defines the max transition time allowed for the signal sourcing the input buffer to prevent any long-term reliability concern which can occur if the applied voltage spends too much time in the mid -supply region defined by VILSS and VIHSS.

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.

We basically need to limit the amount of time the input buffer is exposed to a mid-supply potential. The concern is related to effect on the processor internal logic implementation functioning (reliability concern) in the input buffer caused by shoot-through current that flows from VDD through the input buffer to VSS as the signal transitions through the mid-supply region. The slew rate limits ensure the device is not exposed to this condition for too long over the life of the product.

The risk associated with violating the limit is the possibility of the input buffer failing before the device POH limit.

 There is no maximum input slew rate for the "LVCMOS" buffer when operating at either voltage, so you do not need an RC to slow the signal slew rate. You only need to be concerned with the minimum input slew rate limits defined in the "LVCMOS" Electrical Characteristics table.

The slew rates defined in the Electrical Characteristic sections are a function of long-term reliability, where these parameter values limit the amount of time the input buffer is exposed to a mid-supply potential over the lifetime of the device.  The input slew rates defined in the respective Timing Conditions table are a function of peripheral timing closure, where we only define values required to support the max operating frequency.  It is not possible for TI to define input slew rate values for every possible operating frequency, so we expect the input slew rates to compliant to the limits defined in the Timing Conditions Table for all operating frequencies.  

 The input slew rate limits associated with the GPIO signal function will be relaxed in the next revision of the AM62x datasheet.  The new values are shown in the snapshot inserted below.

Clock Measurement 

I suspect some of their issue is potentially measurement error being introduced by not measuring the input slew rate at the far end of the signal trace.  An LVCMOS signal will have a mid-supply step that occurs any point along the signal trace other than the far end.  This step will add time to a slew rate measurement when measured at any point along the signal path other than the far end.  For example, measuring the slew rate on a signal by placing the probe one inch from the far end of the signal trace will add about 330pf of error to your slew rate measurement.  We need to make sure the slew rate measurements are being taken at the far end of the signal trace, or make adjustments to the measured data to account for the error introduced by the mid-line signal distortion.

Rise/Fall time measurements will typically have an additional 330ps of rise/fall time per inch from where the probe is placed relative to the far end of the signal trace.  You may be able to subtract this additional rise/fall time from your measurements if you know where the probe was place relative to the far end of the signal trace.  If so, this will allow you to determine the actual slew rate that occurs at the far end of the signal trace.

I have inserted a snapshot that shows three signal waveforms, where the one on the left represents the signal shape at the source, the one in the middle represents the signal shape at the middle of the PCB trace, and the one on the right represents the signal shape at the far end of the signal trace.  Note: The PCB trace shown in this snapshot has an AC characteristic impedance that is equal to the output buffer source impedance and a propagation delay of T.  The same mid-supply voltage step occurs when your PCB trace has a AC characteristic impedance of 50 ohms and the output buffer source impedance of about 50 ohms.

The duration of the mid-supply voltage step will be two times the PCB trace delay at the source.  This is how long it takes for the initial mid-supply transition to propagate to the far end of the PCB trace and reflect back to the source.  

 The duration of the mid-supply voltage step will be equal to the PCB trace delay at the middle of the PCB trace.

 There is no mid-supply voltage step at far end of the signal trace.

This mid-supply voltage step stretches the rise/fall time measured by the duration of the mid-supply step, which is a function of where the probe is placed along the PCB trace.  The duration of the mid-supply step measured by probing somewhere in the middle of the signal trace will be the time it takes for the signal to reach the far end of the signal trace after it passes the probe point plus the time it takes for the reflection to return from the far end of the signal trace back to the probe point.  The typical propagation delay of most PCB signal traces is about 167ps/inch.  This is why my 1 inch example mention in the previous reply would have a mid-supply step duration of about two times 167ps.  For this example, you would need to subtract about 334ps from the measured rise/fall time to get a better understanding of what the actual slew rate would be at the far end of the PCB trace.

Source Impedance vs Slew rate 

The source impedance of an output buffer has a big impact on the shape of the signal, including the initial launch voltage and resulting voltage steps that occur at each end of the PCB trace when there are additional reflections from the source end of a signal trace after the initial far end reflection returns to the source and bounce back and forth on the PCB trace until it attenuates.  The best way to resolve reflections on a CMOS signal is to have the output source impedance match the PCB trace impedance so the initial reflection from the far end is completely absorbed or attenuated when it gets back to the source.  Not allowing any additional reflections on the PCB trace will help eliminate under-shot and over-shot conditions.

Slew rate control simply slows the transition rate, which can be important for high speed peripherals since they may need to signal to be valid in short periods of time. However, controlling slew rate doesn’t typically have much impact or create under-shot and over-shot conditions on the signals.

AM623: Rise/Fall Time Requirement of MMC_CLK

We define timing requirements for AM62x inputs and define timing characteristics for AM62x outputs.

We do not define any rise/fall switching characteristics associated with AM62x outputs because these characteristics are very dependent on the specific system implementation. The system designer must use the IBIS model of each device connected to a signal and the PCB signal trace extractions in a simulation to determine the rise/fall time of any signal being sourced by AM62x.

Connecting capacitor (load) at the LVCMOS IO output for EMI control

There is a Timing Conditions table at the beginning of each peripheral timing section in the datasheet, where the maximum capacitance is defined. Your system should be designed to be compliant to the max capacitance defined in the respective Timing Conditions table.

The max output load capacitive defined in the datasheet is the combination of everything connected to the pin.

Connecting a 100pf capacitor directly to the output buffer causes large peak current to flow through the AM64x power rails and output buffer to the capacitor. This large capacitive load applies more stress to the output buffer than expected and introduces larger than expected ground bounce which introduces noise into the entire AM64x device.

Inserting a series resistor before any discrete capacitor load will reduce the current that flows through the AM64x power rails and output buffer. However, the RC circuit would need to be placed near the AM64x device to be effective in reducing the signal slew rate which is what you are trying to do to reduce EMI.

EMI issues is a typically a system implementation issue and has many variables which influence the profile of radiated emissions. PCB layout issues are the mostly likely contributor. For example, a common contribution to EMI has been seen when customers route signals through board to board connectors or board to cable connectors without low loop inductance return ground paths which can cause signals to radiate noise. Is the SPI_CLK signal routed such that it has a low impedance return reference along the entire path of the signal?  For example, does the signal cross any split reference planes or does it transition from one reference plane to another reference plane without a nearby a stitching via or stitching capacitor?

Slew Rate control

The IO cells used in AM64x do not have slew rate control.

The IO cells were designed to include drive strength control, which effectively changes the source impedance of the output buffer.  Changing the impedance of the output buffer may have a small impact on the signal slew rate, but that is not the purpose of implementing drive strength control.  The primary purpose for including a way to change output buffer drive strength is to match the impedance of an output buffer to the impedance of a PCB signal trace.  This drive strength control function is used to eliminate signal distortion that is the result of reflections on the signal traces when the output buffer impedance doesn’t match the AC impedance of the signal trace.

 The drive strength control implemented in AM64x has been set to fixed values such that the output buffers source impedance matches a typical PCB trace impedance.  The Am64x LVCMOS IOs were timing closed with the default drive strength. Therefore, we do not recommend changing the drive strength since this could be introducing signal timing issues with the attached device.

 In summary, there is no way to internally control the slew rate of a GPIO output signal.  They could insert a low pass filter on the signal to reduce the slew rate.

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.

Drive Strength Configuration

TI currently does not support configuring any other drive strength besides the nominal (default) value for SDIO and LVCMOS buffers, as the nominal value is the only configuration at which chip-level STA (Static Timing Analysis) is closed. The nominal value corresponds to a 40Ω for SDIO and 60Ω for LVCMOS. The IBIS model has been updated to contain only drive strengths where the timing is closed internally.
We do not currently support changing the drive strength.
The SOC was designed for proper operation when using the default drive strength.
Changing the drive strength may cause functional issues. Therefore, we currently do not support changing drive strengths.
The drive strength must remain in the default state since this is the only condition used during timing closure of the peripherals.

The latest IBIS model on TI.com should have the updated configurations. Ensure customer uses the update IBIS model on TI.com.

Will the drive strength information be included in the Datasheet?

This type of information is provided in the device IBIS file. We only provide these details in the IBIS model.

Customers that need electrical characteristics associated with IOs are typically doing simulations to validate their design. Therefore, we provide these details in the IBIS file to make it easy for our customers to import the data into their simulation environment. The IBIS files are created using an automated flow, where the information is taken directly form the design. This prevents data entry errors that may occur if we manually entered this information in the datasheet. We decided several years ago to stop including many of the IO electrical characteristics in the datasheet and only provide this information in the IBIS file.

The DRV_STR setting doesn't directly impact the DC mA capacity.  It does have an affect on the transition/edge of the signal

nRSTOUT for MCU_PORz Slew

Please keep in mind the AM62Ax device requires the MCU_PORz input to have a maximum rise/fall time of 1000ns. This may be difficult to achieve with a pull-up on a signal sourced from an open-drain output buffer. You may need to buffer the open-drain signal with a push-pull buffer that has hysteresis on its input to ensure the AM62Ax device never receives a short reset pulse that violates the minimum pulse duration defined in the "MCU_PORz Timing Requirements" table. For example, it may be possible for noise to couple on the slow rising open-drain signal just as it crosses the input buffer threshold which could cause a short glitch on the reset signal. Normal device operation could be compromised if this occurs.

See the "Input Slew Rate" parameter in the "Fail-Safe Reset (FS RESET) Electrical Characteristics" table.

The MCU_PORz input is the only input on the AM62x device that is fail-safe and 3.3v tolerant. Therefore, you can pull the MCU_PORz signal to 1.8V or 3.3V.

See the "Steady-state max voltage at all fail-safe IO pins" parameter for MCU_PORz in the "Absolute Maximum Ratings" table.

mid-supply potential to LVCMOS

Applying a mid-supply potential to any CMOS input buffer that is enabled will partially turn on both p-channel and n-channels in the input buffer. This causes shoot-through current to flow from the IO supply to ground. This shoot-through current could damage the input buffer if the condition remains for extended periods of time. Therefore, it is important for the system design to turn off any conflicting internal pulls as soon as possible.

Connecting Open drain output together 

 https://e2e.ti.com/support/logic-group/logic/f/logic-forum/865215/faq-with-open-drain-outputs-can-i-use-them-to-shift-a-logic-voltage-level-connect-the-outputs-directly-together-force-a-voltage-node-to-zero 

With an open-drain output, there is no danger of one output being HIGH and another being LOW since all outputs are either LOW or Hi-Z. In the above image we show how three open-drain buffers can be combined to produce a 3-input AND gate function. It is important to note that the output signal has the same limitation as the previous use-case: the signal can either be fast or low power, but not both.

Configuring GPIO as open drain outputs

It depends on the IO cell associated with the pin being used for the GPIO function in question. Look in the Buffer Type column of the Pin Attributes table to determine the IO cell implemented on the pin in question. A limited number of pins implement I2C open-drain fail-safe (I2C OD FS) IOs. These IOs only have open-drain output buffers, so you do not need to do anything to configure these IOs to operate as open-drain outputs. Most of the other pins that can be used as a GPIO implement LVCMOS IOs, which have push-pull output buffers. If you select one of these pins for your GPIO, they can be configured to operate as open-drain outputs by configuring the GPIO module to source a constant low output and toggle the output enable. The output buffer will drive low when enabled and will be high impedance when disabled.

Note: The (I2C OD FS) are the only IOs which are fail-safe. The other IOs do not allow any potential greater than (VDD + 0.3V) to be applied.  This means you can not source any potential to these pins when power is off. So make all attached devices with can source a potential to these IOs are powered from the same power supply that is sourcing the respective IO power rail. This eliminates any risk of this occurring.  

Processor GPIO used for resetting peripherals including OSPI, eMMC 

 RE: AM620-Q1: reset of eMMC circuit on EVM 

AM62x EVM design for resetting eMMC using an AND gate (see schematics) is a solution we would also recommend for series production ... or do we consider that as a functional demo only?

The AND gate produces an eMMC device reset when either RESETSTATZ is asserted low or the GPIO connected to GPIO_eMMC_RSTn is asserted low. The RESETSTATZ signal will be asserted when the AM62x receives a cold reset or a warm reset. This signal is needed to ensure the eMMC device is returned to its initial operating state any time the AM62x device is reset. The GPIO_eMMC_RSTn is provided to allow the eMMC software driver to reset the eMMC device in case it wants to reset the entire eMMC subsystem. 

You will need to check the eMMC software driver you plan to use to know if this function is available and to understand how you tell it which GPIO was used for this function.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1283208/am623-am623-question-on-sk-am62-design/4866328 

I have some doubts about the RST circuit design of eMMC;

         U58 is an AND gate, so the output is only high when inputs 1 and 2 are high, otherwise it is low. However, there is also an up pull on the RST side, so the RST side is always high, right?

         Please help explain, thank you

The GPIO controlled input originates from a AM62x IO that is turned off until the eMMC driver software initializes it to be a software-controlled reset output. The input allows the eMMC software driver to reset the eMMC device without resetting the entire system. The external pull-up on this signal is required to hold the undriven signal high until software initializes the associated GPIO. The device would not be able to boot from eMMC if the signal had an external pull-down attached since the ROM codes doesn't know which GPIO is used to implement a software reset.

The RESETSTATz input will be driven low when the AM62x device is being reset (power-on reset or warm reset). This input allows the eMMC device to be reset for the first time after the system receives power or if the AM62x device encounters a warm reset event like a watchdog timeout.

I agree the AND gate output is always driven, so I'm not sure why the hardware team placed a pull-up on that signal. This can be optional.

 RE: AM62A3-Q1: HW:SDCD Interface 

 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.

Regards,

Sreenivasa

Hi Board Designers, 

Refer below FAQs

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1443807/faq-am6442-how-does-lvcmos-buffer-behavior

Question to Absolute maximum ratings

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1490743/am2434-question-to-absolute-maximum-ratings/5730902

Below is Absolute Maximum Ratings in Datasheet (SPRSP65G).

My customer is asking what is the reason the maximum voltage at IO pin is IO supply voltage+0.3V.
Is this to prevent an internal ESD diode from turning on?
If so, what is a problem with the internal ESD diode turning on?

Yes, the ESD protection circuits will turn on if the input is greater than IO supply voltage+0.3V.

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 that occur during device handling and PCB assembly. The ESD protection circuits are not designed for steady-state DC current or provide any system-level ESD protection once the device has been installed on a PCB.

peaves said: 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 that occur during device handling and PCB assembly.
Do you have specific number for "short-duration"? 50msec duration would damage the device?

We do not allow any injection current from an IO voltage potential greater than IO supply voltage+0.3V, for any period of time.

My comment about short-duration was simply a reference to the typical ESD event profile that falls within the limits defined by the ESD standards listed in the ESD Rating table of the datasheet. As mentioned before, the ESD circuits were only designed to protect the device from 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 circuits were not designed to protect the device from system-level ESD events that occur after being installed on a PCB. However, the ESD circuits are still connected to the IOs. So, we must ensure the circuits are not damaged from unexpected injection current.

Residual Voltage / Injection current

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

Hi Board Designers, 

Refer below

1) What's the max current input and output for SDIO DATA/CMD line? (2) What's mean for "input leakage current"?

(3) Could we "remove" external PU resistor for SDIO communication? (connect device is WiFi module, not eMMC or SD)
Because of PCBA space limitation. we try to remove external PU resistor, and we found SDIO level become 1.2V. Does it have side effect?

(4) Does SDIO interface support internal PU resistor by register setting? Could we use internal SDIO PU resistor to replace external resistor?

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.

one question, Do we have minimum Low Level input current and High Level input Current for SDIO? Base on "7.8.5 SDIO Electrical Characteristics", I do not see related parameter. So I am not sure this is a right question.

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.

Regards,

Sreenivasa

Hi Board Designers, 

Refer below

Driving an LED - Source or Sink using processor LVCMOS IO 

 We do not expect our outputs to be used to direct drive LEDs.  The output currents defined in the datasheet should not be used as limits for steady-state currents.  The datasheet output current limits are only expected when charging or discharging signal capacitance to transition a signal from low to high or from high to low.  Once the signal reaches a valid logic state, the steady-state current is expected to be much lower.  The outputs can tolerate some steady-state current as required to over-drive typical pull resistors, but we do not expect large stead-state currents like what is needed to drive an LED.

When driving an LED for a short duration using processor LVCMOS IO, the IO is recommended to be configured as output to be able to sink or source current

The LED supply is recommended to be powered from the same IO supply for IO supply group power source referenced by the LVCMOS IO.

The input impedance of the LVCMOS input is high. The current drawn is the leakage.

Recommendation is for customer to use a transistor or FET logic to drive the LED at 5V and control using the processor IO.

The recommendation is to use a transistor or FET logic to drive the LED at 5V and control using the processor IO.

We did not design our IOs to be LED drivers.  We expect our outputs to source signals that only connected to week pull resistors and CMOS inputs that have minimum steady-state leakage current. The recommendation is to insert a buffer at the processor IO output to eliminate the IOs from having to drive constant current into the LED.

Due to a design issue with the board, there is a period of time during which the high-level output pin of AM2431 is shorted to a low-level output pin of another IC.

Could you please provide the maximum allowable current for LVCMOS operating at 3.3V?

We do not expect our output buffers to ever be used in an application that requires it to source any significant DC steady-state current.  We only expect the output buffer to source significant current when the signal is changing logic states.  The only DC steady-state current expected is associated with holding the signal at the opposite logic state of a weak pull resistor.

The peak current that occurs during this contention condition could be very high and may damage one or both devices.  They definitely should not allow the source impedance of the two output buffers to be what limits the current.  They need to resolve the conflict, or at insert a current limiting resistor between the two devices.  However, this current liming resistor may have a significant impact on signal quality if the signal needs to operate with a fast toggle rate.

We do not define a max DC current.  We only define an output current operating condition, where we know the output buffer is able to drive a signal below the VOL limit or above the VOH limit.  They should be okay if they limit the current to less than 3mA, which is the output current operating condition that is being used for the VOH

Regards,

Sreenivasa

Hi Board Designers, 

Refer below input on the LVCMOS slew

What is the applicable range of the throughput rate spec? It is from 10% to 90%

Inputs related to pin capacitance 

The IBIS models have C_pkg (package capacitance, universal min/max for all pins) and C_comp (die capacitance, unique for each buffer type) that can be combined together to get the total capacitance for a pin.

Regards,

Sreenivasa

Hi Board Designers, 

Refer below input on connecting unused IOs

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1452150/am62a7-q1-unused-ball-l17-gpmc0_oen_ren/5570179

in case the ball L17 GPMC0_OEN_REN is not used, can the ball let open or a pull-up/down is recommended?

The ball can be left unconnected (no signal trace connected to the ball) as long as your system software never turns on the input buffer via the RX enable bit of the associated padconfig register.

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.

Refer pin connectivity section ffor notes related to connection of GPIOs.

(+) [FAQ] AM623: Power / GND pins associated with GPMC_CLK - Processors forum - Processors - TI E2E support forums

Which Power / GND pins are most associated with driving the GPMC0_CLK signal for the AM623 AALW package? 

I received a reply from our packaging team. They said ball P18 is the closest to the IO cell connected to ball P25. 

Regards,

Sreenivasa

Hi Board Designers, 

AM625: Disturbance on OSPI CLK connected to SPI NOR

Providing multiple chip select pins on this peripheral makes someone think they can connect multiple devices, and is expected to understand the implementation is very problematic. 

The problem with connecting multiple devices is related to your observation on the clock. You see this distortion on the source end of the signal trace because the output buffer has about the same source impedance as the signal trace. When the signal changes from low to high or high to low, the voltage applied to the signal is divided by the ratio of output buffer source impedance and the signal trace impedance. It is basically a voltage divider that results in a mid-supply voltage being applied to the signal. This mid-supply voltage propagates down the signal trace until it encounters a high-impedance or open-circuit, where the mismatch in impedance results in an in-phase reflection that causes the voltage at the far end to make a continuous transition from VDD to VSS or VSS to VDD. This reflection returns back to the source, where the voltage at the source will not continue to VDD or VSS until this reflection has returned. The length of the mid-supply step function will be equal to two times the propagation time of the clock signal trace. The step function gets shorter as you get closer to the end of the signal trace, but not completely gone until the very end.

A device connected anywhere other than the far end of the signal trace will observe the same step function on the clock signal. Connecting a device clock input anywhere in the middle of a clock signal trace is a very bad design practice because there is a good chance the output of the clock input buffer of this device will generate internal clock glitches when this mid-supply voltage pauses near the switching threshold of the input buffer. You cannot split the signal trace into two paths without creating impedance discontinuities which also causes signal distortion. Inserting buffers will resolve the impedance mismatch issue but inserts delay in the clock path, which may cause a timing violation because the peripheral was timing closed assuming a direct connection without any buffer delays.

Connecting your NOR memory device to the middle of the clock signal was a mistake. You must resolve this issue by disconnecting any signal trace that extends beyond the attached device to prevent any internal clock glitch issues.

Most of the AM62x pins power-up turned off, so you need include external pull resistors to hold any attached device inputs in a valid logic state until the IOs and associated peripheral module has been initialized by software. You should never allow CMOS inputs to float. this is especially true for the AM62x inputs. All AM62x inputs which have been enabled must be held in a valid logic state that is above the VIHSS or VILSS as defined in the respective electrical characteristics section of the datasheet. The AM62x device could be damaged if your design allows any enabled inputs to float to mid-supply voltages for an accumulated period of time over the life of the product.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1164397/am625-disturance-on-ospi-clk-connected-to-spi-nor/4388721

Regards,

Sreenivasa

Hi Board Designers, 

About SPI signal series resistor

A value of 33 ohms may actually be better than 22 ohms. The most important thing is placing the resistor close to the AM64x device to minimize the signal trace length that connect the series resistor to the AM64x pin. This is required because the SPI clock pin is operating as input and output at the same time, where the internal data capture clock is looped back in the AM64x IO buffer. This is done to help with timing closure of SPI by inserted an equivalent delay in the looped back clock as the returned data path sees with the delay inserted by the clock output buffer and data input buffer. However, this approach impacts signal integrity at the looped back clock pin.

The help explain this issue, lets assume the output impedance is equal to the trace impedance. In this case the source end of the signal trace will only transition to mid-supply initially when the clock toggles. The signal will propagate the far end of the signal trace where it encounters a high-impedance mismatch which causes an equivalent amplitude reflection that returns to the source. For the time it take for the signal to propagate down and back, the voltage applied to the source pin will remain mid-supply. This is very likely to create glitches on the clock being looped back into the SPI controller. These glitches may over-clock the state machine and cause unpredictable operation. Adding a series resistor allows the voltage to step beyond the switching threshold, which prevents glitches. A 33 ohm will allow the voltage to step further away from the switching threshold than the 22 ohm. Increasing the resistor too much will compromise clock transition time, which may impact performance. I would avoid going higher than 33 ohms unless you observe an issue where the step function on the signal is causing problems.

The signal trace that connects between the pin and resistor will create a similar step and this is unavoidable. However, the step will be filtered by the input buffer if short. This is why it is important to keep this trace short.

Hopefully, this explains why we require these resistors and why they need to be close to the source pin 

Regards,

Sreenivasa

Hi Board Designers, 

About series resistor on clock input

e2e.ti.com/.../3851264

I did not see any de-coupling capacitors between on the AM335x VDDSHV4 power pin after low pass filter L704. Were these accidently omitted in the snapshots provided? If not, each power pin needs local de-coupling capacitors after their respective low pass filters.

I’m concern with the SD Card ground connections. Hopefully the SD Card VSS1 and VSS2 pins are connected directly to the same ground as the AM335x device. I assume the other grounds shown for the SD Card are simply the metal chassis ground and they are not part of the SD Card signal and power ground connections.

They should not be using a zero ohm resistor for R514. This should be a 22 - 50 ohm resistor. The MMC/SD host controller in AM335x loops the clock back at the pin to improve timing margin for the internal circuits. However, there is a negative side effect of implementing clock loopback on a pin. The clock signal will be distorted on the source end of a signal trace and a series resistor of 22 - 50 ohms is required to modify the signal distortion such that is does not create a glitch on the looped back clock signal.

I will explain what happens. The clock output buffer inside AM335x has a source impedance of about 30- 50 ohms and a typical PCB signal trace has a characteristic impedance in the range of 40 - 60 ohms. When the output buffer toggles the signal from low to high or high to low, the voltage of the pin which sits between the output buffer and the PCB signal trace will not transition to the expected voltage immediately. This is because the output buffer impedance and trace impedance create voltage divider that causes the pin to step to a mid-supply voltage for a short time. This step will last as long as it takes for the clock signal to travel down the PCB signal trace to the SD Card, where it encounters a high impedance load that creates a reflection that allow the voltage  to increase to VDD or VSS. The amplitude of the mid-supply voltage step may be near the AM335x clock buffer input switching threshold, which allows noise to create a glitch on the AM335x internal clock. The series resistor raises the impedance of the PCB portion of the voltage divider such that the voltage at the pin steps above or below the switching threshold.

I suspect this is what is causing the instability and the reduced clock amplitude is contributing to the issue.

I explained the purpose of the series resistor. A series termination resistor in the range of 22 - 50 ohms should be located as close as possible to the AM335x MMC0_CLK pin to shift the clock distortion away from the looped back clock input buffer switching threshold. 

However, how do we choose the best value for series resistor? I haven't observed the difference from waveform when changing R514 from 0 to 22 Ohm.

What you observe on this signal depends on where you connected the probe, the bandwidth of your probe/scope, and quality of your scope probe ground. 

You will need a very high bandwidth probe and scope to observe short over-shoot, under-shoot, and non-monotonic events on the signal. I recommend using a low capacitance FET probe with a very-very short low loop inductance ground.

You will see a mid-supply step on the signal when probing near the source. This occurs because the output impedance of the MMC0_CLK output buffer, series termination resistor, and characteristic impedance of the PCB signal trace creates a voltage divider. The voltage divider output is applied to the source end of the PCB signal trace. This voltage propagates down the trace to the far end where it encounters a high impedance load which causes a in-phase reflection that returns to the source. Therefore, the voltage transition observed on the far end will be a continuous transition between VSS and VDD. The is not the case for the source end, as it steps to a mid-supply determined by the voltage divider values and the transition only continues to VDD or VSS once the reflection returns from the far end. You need to select a series resistor value that allows the MMC0_CLK pin to step through the voltage of (VDDSHV4 / 2) without pause. I suggest the step observed on the MMC0_CLK pin should be at least 200mv above (VDDSHV4 / 2) on the rising edge and at least 200mv below (VDDSHV4 / 2) on the falling edge.

Regards,

Sreenivasa

Hi Board Designers, 

Refer below for information related to PMIC_LPM_EN0

AUDIO-AM62D-EVM: PMIC_LPM_EN0(D12) pin is getting Reset when it is Pull Down (Direction is out)

1.what is the function of PMIC_LPM_EN0(D12) pin?

2. What is the use case of this pin?

3.What is the default pin configuration of this?
Note: When this pin configured as Pull Down (Direction is out), system getting reset, when this pin configured as Pull Up (Direction is out), system is working fine  

Pin D12 defaults to the PMIC_LPM_EN0 signal function. This signal is used to control the PMIC.
When using Partial IO low power mode, the signal is used to turn off the switched power rails when software configures the Partial IO logic to enter Partial IO low power mode and turns on the switched power rails back on when the always powered Partial IO logic detects a wakeup event.
When using the PMIC_LPM_EN0 signal as described above, an external pull-up to the VDDSHV_CANUART power source is required. The pin will be high-Z during reset, which allows the pull-up to turn on the PMIC as soon as the always on VDDSHV_CANUART supply ramps up. The pin will be driven high once the device is released from reset (rising edge of MCU_PORz). It will remain high until the device has been put into CANUART mode and told to enter low power, where it is driven low to turn off the PMIC. It will be driven high once again when the CANUART detects an external wakeup event. When not using Partial IO low power mode, the signal can be used to change the operating mode of the PMIC to a lower power configuration when software places the device in deep sleep mode. After the device has booted, software can configure pin D12 to function as MCU_GPIO_22 if the PMIC_LPM_EN0 signal function is not required.

Note: The explanation is applicable to AM62x, AM62A, AM62D-Q1 and AM62P family of processors.

Regards,

Sreenivasa

Hi Board Designers, 

Refer below for information related to connection of supplies, NC pins and unused SOC GPIOs

Refer pin connectivity section for the below notes 

(11) AM62A7-Q1: Handling of floating pins - Interface forum - Interface - TI E2E support forums

The AM62A manual provides instructions on the unused configurations for some of the pins.But not all pins were covered.

May I ask if the other unused pins of AM62A7, such as RGMII, eMMC and GPIO, require external hardware pull-up/pull-down configuration? Or should they be configured in the initial state through software? Or can I leave the unused pins unconnected?

It is not possible for the table you referenced to address all possible combinations of connectivity options. The connection recommendations included in the table are meant to address the most likely pins that need special consideration. For example, the boot mode inputs must be tied-off to indicate your specific system boot sequence.

There is a note following the table that explains how many of the configurable device IOs are turned off by default. 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 if allowed to float, and this condition could damage the IO cell. You must ensure your application software never enables any of the AM62Ax inputs buffers when the attached signal is not pulled or driven to a valid logic state.

The comment above does not address requirements of devices you attach to AM62Ax. It may be necessary to include an external pull on any signal connecting AM62Ax to the input of an attached device. The external pull may be needed to hold the input of the attached device in a valid logic state until the AM62Ax application software has booted and configures the selected peripheral and IO such that the signal is driven.

The system designer is expected to understand how the AM62Ax and attached device functions, so they can design their system to provide the appropriate connectivity and configure their application software to accommodate the connectivity requirements for all operating conditions beginning with initial power-on, going through the boot sequencies, during normal operation, and ending with power-off.

(29) [FAQ] AM625 / AM623 / AM620-Q1 / AM62L / AM62Ax / AM62D-Q1 / AM62Px / AM64x / AM243x Design Recommendations / Commonly Observed Errors during Custom board hardware design – SOC peripherals and IOs connection when not used - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

Hi Board Designers, 

Additional references:

(+) [FAQ] AM62x, AM62Ax, AM62D-Q1, AM62L, AM62Px, AM64x, AM243x, Custom board hardware design – How to handle Used / Unused Pins / Peripherals and add pullup or pulldown? (e.g. GPIOs, SERDES, USB, CSI, MMC (eMMC, SD-card), CSI, OLDI, DSI, CAP_VDDSx, .....) - Processors forum - Processors - TI E2E support forums

(+) AM6442: GPIO Behavior on TMDS64EVM When Connected to GND or VCC and supported pulls - Processors forum - Processors - TI E2E support forums

Supported pullup or pulldown for IO buffer type SDIO, eMMCPHY, LVCMOS and configuration during reset and after reset

ould you please provide the permissible resistor value range when fixing the voltage externally for the SoC input pins? Specifically, I would like to know the acceptable range when pulling the pins High or Low on the board.

I would prefer to connect with the lowest possible impedance.
For confirmation, please also advise on the following pins (some were previously inquired about):

• RESET input pins: MCU_RESETz, RESET_REQz
• BOOTMODE pins

Any though on why you would want to use a low impedance resistor?  I assume you may be concerned with noise coupling to the signal if only connected with a high impedance pull.  If this is the concern, keeping the signal trace short is just as important since long signal traces can act like an antenna and pickup noise.  If they have a long signal trace connected, I would recommend placing the low impedance pull-up near the processor input pin so the unterminated high impedance end of the signal trace develops the voltage potential when noise is coupled into the signal trace rather than the low impedance terminated end of the signal trace.

Considering worst case scenario with calculations based on the Sections, Recommended Operating Conditions and LVCMOS Electrical Characteristics of the AM62Px Datasheet:

I assume you reuse the SK-AM62P-LP schematic, and VDDSH3=3.3V. In worst case, the LVCMOS High and Low output levels to be: VOH(max)= VDDSHV3max =3.465V  and VOL(min)=V_gnd = 0V

Under "boot mode pins wrongly initialized by SW as outputs" scenario you should have PU and PD load current limited to: 

With PU=2k: I_OL = ( VDD(max) - VOL(min) ) / Rpd ~ ( VDDSHV3(max) - V_gnd ) / Rpu = ( 3.465 - 0V ) / 2k = 1.73 mA < IOL(VOL_MAX) = 5 mA

With PD=2k: I_OH = ( VOH(max) - V_gnd ) / Rpd ~ ( VDDSHV3(max) - V_gnd ) / Rpd =  ( 3.465V - 0V ) / 2k = 1.73 mA < IOH(VOH_MIN) = 9 mA

Therefore using highest possible in the range 1K ... 2K shall be ok.

Although the above calculations are within the data sheet spec this current is expected to be sourced or sunk for a short duration.

If the bootmode pin is expected to be an output for unexpectedly long time, the recommendation is to reduce the current.

A 10K or worst case 4.7K is recommended in these use cases.

Regards,

Sreenivasa

Hi Board Designers, 

Inputs regarding the specifications of the AM62P MCU_ERRORn (G6) pin:

Q1.
Section 6.3.3.3 of the TRM states:
"While in Power-On-Reset, the Error Pin is active (asserted low). SoC drives a Low via a weak internal pull-down."
Does this mean that during Power-On-Reset, the SoC does not actively drive the MCU_ERRORn pin low as a CMOS output, but instead pulls it low using a weak internal pull-down resistor?

Q2.
Is the internal pull-down resistor for MCU_ERRORn the one specified in the Data Sheet section 6.8.7 “LVCMOS Electrical Characteristics” as RPD: 15–30 kΩ?

Q3.
If we connect an external pull-down resistor to the MCU_ERRORn pin, is there a recommended resistance value?

A1. The IO cell associated with the MCU_ERRORn pin has its input and output buffers turned off, and its internal pull-down turned on while MCU_PORz is asserted. The input buffer and output buffers will be turned on, and the internal pull-down will remain turned on when MCU_PORz is de-asserted. The ESM will drive a high logic state shorty after MCU_PORz is de-asserted, and this state will remain until the ESM has been initialized and an error detected.

A2. Yes, the IO cell associated with pin G6 is the LVCMOS buffer type. You need to understand the internal pulls are not linear resistors. The pull resistance increases as the signal potential approaches the power rail that is pulling the signal. The datasheet values represent the range of pull resistance expected when the signal is pulled to the opposite power rail. We do not define the internal pull resistance for any other operating condition. You will need to use an external resistor if your application requires a linear pull resistor.

A3. The VOH and IOH parameter values represent a single data point that says the output buffer is able to source a voltage greater than VDD - 0.45 when a 3mA load is connected. The voltage is likely to be much higher than VDD - 0.45V with a lower current load. However, you will need to use the device IBIS model to determine the output voltage for any other load condition.

Note: The input buffer associated with this IO cell is enabled to allow the MCU_ERRORn signal to be looped back into the device through the IO cell, so you need to make sure the steady state potential applied to pin G6 is greater than VIHSS (0.85VDD) or less than VILSS (0.3VDD) to prevent any long-term reliability issues with the input buffer. You will need to consider the worst-case input leakage of the AM62Px IO cell (10uA), the min resistance of the internal pull-down (15k), the worst-case input leakage of all other devices connected to the MCU_ERRORn signal, as well as the load presented by the external resistor when trying to determine the output voltage when driven high.

(+) AM62A7-Q1: MCU_ERRORN pull down or pull up - Processors forum - Processors - TI E2E support forums

(+) AM623: MCU_ERRORn during boot - Processors forum - Processors - TI E2E support forums

the MCU_ERROR signal is an output of the ESM module and is not used by the ROM code.  During active reset (ie, when PORz signal is active), the IO has an internal pull down to keep the signal low.  Once reset is deasserted (to the SoC, and subsequently to the ESM module), the ESM module will drive the signal high indicating no error (MCU_ERRORn defaults active low), but at this point the ESM module would need to be configured by the application before begin used.  The ROM does not do this, but the bootloader could (I'm not sure if the current u-boot in the SDK uses the ESM, but this certainly could be configured to be used.)

I don't think the MCU_ERRORn signal was intended to be used so early in the boot process as you describe.  It was more for application level errors, and a prerequisite is that you have to configure the ESM module for things like interrupts, signal type, etc.

Regards,

Sreenivasa

Hi Board Designers, 

Inputs regarding padconfig bit TX_DIS

Data sheet reference 

Pin attributes table 

BALL STATE DURING RESET RX/TX/PULL: State of the terminal while MCU_PORz is asserted, where RXdefines the state of the input buffer, TX defines the state of the output buffer, and PULL defines the state of

internal pull resistors:

• RX (Input buffer)

– Off: The input buffer is disabled.

– On: The input buffer is enabled.

• TX (Output buffer)

– Off: The output buffer is disabled.

– Low: The output buffer is enabled and drives VOL.

• PULL (Internal pull resistors)

– Off: Internal pull resistors are turned off.

– Up: Internal pull-up resistor is turned on.

– Down: Internal pull-down resistor is turned on.

 NA: Not Applicable.

• An empty box means Not Applicable.

The PADCONF regs can independently enable or disable the input path (RX_ENABLE) and the output path (TX_DIS). This might conceptually be done to minimize power consumption. Or as another example, you may want to "guarantee" that a particular GPIO is limited to functioning as an input (RX_ENABLE=1) and should never be allowed to "accidentally" drive an output (TX_DIS=1) (though "accidentally" having GPIO to drive an output can only happen in the case of a software bug)

Once those two buffers are enabled, then the MUXMODE dictates which IP can dynamically control the corresponding IO.

If for example you're in GPIO mux mode ...

At any given instant the output path can be high-z or actively driven. If you tell the pin to act as an output, then the GPIO module drives the "output_enable" of the IO buffer (making it "not" high-z) and the output value from the GPIO module is driven on the output *and* reflected back on the input path if the RX_ENABLE is enabled. And the GPIO IN value will reflect the state of the output value.

If the RX_ENABLE is "disabled" then you would not see the GP In reflecting the GP Out.

Similarly, if TX_DIS=1 then the GPIO "output enable" is gated off and regardless of what is set in GP OUT will not reflect on the output pad.

Additional inputs i received from our device expert for TX_DIS.

This bit was added because the pin mux logic is not glitch free when changing modes. For example, the pin mux logic may connect the output of any of the signal function to the IO cell for a very short duration when switching from one mode to another. This may cause the attached signal to glitch to an unknown logic state or multiple unknown logic states before settling to the logic state of the newly selected signal function. This glitch may be undesirable for some applications. If that is the case, the TX_DIS bit provides a way for the application software to force the output buffer off before making the mode change. Note: The attached device may require an external pull or the internal pull to be turned on to hold the signal in a known state while the TX_DIS bit is set. The input buffer associated with the IO on our device will have a similar requirement if the input buffer is enabled with the RXACTIVE bit. An alternative for protecting our IO would be to turn off the associated input buffer before turning off the output buffer.

Once the mode has been changed, the TX_DIS bit can be returned to its functional state. The RXACTIVE could be turned back on if it had to be turned off. Then software can begin using the new signal function.

In some cases the application may not care if the signal glitches. If so, this process of disabling the output buffer during a mode change may not be necessary.

(+) AM623: AM623 Radiated Emissions - Processors forum - Processors - TI E2E support forums

I was concerned the final stage of the output buffer was the only portion being disabled by the TX_DIS bit, and the level-shifters/pre-drivers in the output buffer were still consuming power at the toggle rate when the TX_DIS bit is set. I asked our IO designer, and he confirmed the entire output path is disable when the TX_DIS bit is set. Therefore, VDD_CORE is the only power rail that would be exposed to any noise generated by GPMC activity once you set the TX_DIS bit high in every PADCONFIG register associated with a GPMC signal function.

Inquiry on TX_DIS Configuration for LVCMOS (RGMII1) Pins Used with MUXMOD: 0

The TX_DIS bit in the PADCONFIG registers provides a way to over-ride to the output enable signal coming from the internal module selected by the pin mux logic. When set high, the output buffer will be forced off.

This function was added to the IOs as a way to force the outputs off when switching mux modes because the pin mux logic is not glitch free. It is possible for the outputs to be driven to unexpected states when changing mux mode values. For example, let's say you were switching from mode 8 to mode 1, neither of these mux modes are driving the buffer, but mode 3 associated with this IO is driving a high logic state. The pin mux logic may transition through mode 3 on its way from mode 8 to mode 1. If so, the output buffer will try to drive the high logic state on the device pin for a few ns as the pin mux decode logic settles.

You are expected to set TX_DIS bit high before changing the mux mode value and change it back to low if the selected signal function is an output.

When using the following JTAG pins with MUXMOD: 0, could you please advise the value that should be set for TX_DIS?

The Padconfiguration registers TX_DIS bit is used to enable (active LOW level) the output path for different IP hardware interfaces at the AM62P-Q1 SoC pin level.

Clarif. The pad-configuration registers that control the AM62P-Q1 JTAG signals at SoC level have MuxMode=0 as the ONLY valid Muxmode choice. The JTAG interface signals are selected on the relevant SoC pins by default after POR. In my understanding, the software shall not change the MuxMode bitfield to another value, and make sure that MuxMode is kept only at the 0x0 valid value.

TCK pin:       set TX_DIS = HIGH   -> Expl.: AM62P JTAG test clock input pulsed from outside by the test controlling equipment -( debugger, others.), therefore this pin output buffer is disabled

TRSTn pin:   set TX_DIS = HIGH   -> Expl.: AM62P JTAG test reset input, therefore this pin output buffer is disabled

TDI pin:         set TX_DIS = HIGH  -> Expl.: AM62P JTAG serial data input, therefore this pin output buffer is disabled

TDO pin:       set TX_DIS = LO      -> Expl.: AM62P JTAG serial data output, therefore this pin output buffer is enabled

TMS pin:       set TX_DIS = HIGH  -> Expl.: AM62P JTAG serial test mode select input, therefore this pin output buffer is disabled

EMU0 pin:     set TX_DIS = LO      -> Expl.: AM62P JTAG EMU0 control bidirectional I/O pin, therefore this pin output buffer is enabled

EMU1 pin:     set TX_DIS = LO      -> Expl.: AM62P JTAG EMU1 control bidirectional I/O pin, therefore this pin output buffer is enabled

The TX_DIS bit in the PADCONFIG registers provides a way to over-ride to the output enable signal coming from the internal module selected by the pin mux logic. When set high, the output buffer will be forced off.

This function was added to the IOs as a way to force the outputs off when switching mux modes because the pin mux logic is not glitch free. It is possible for the outputs to be driven to unexpected states when changing mux mode values. For example, let's say you were switching from mode 8 to mode 1, neither of these mux modes are driving the buffer, but mode 3 associated with this IO is driving a high logic state. The pin mux logic may transition through mode 3 on its way from mode 8 to mode 1. If so, the output buffer will try to drive the high logic state on the device pin for a few ns as the pin mux decode logic settles.

You are expected to set TX_DIS bit high before changing the mux mode value and change it back to low if the selected signal function is an output.

Note: In some use cases, the attached debugger may try to use the EMU[1:0] signals in a bi-directional mode.  This is why we recommend configuring the TX_DIS bits associated with these pins low.

AM62P-Q1: Regarding UART RXD Pin Configuration (TX_DIS=0) in SysConfig “Debug Log” Section
1. Is it correct that there is no issue using the UART RXD pin configured in the SysConfig “Debug Log” section with TX_DIS set to 0?
In other words, even if TX_DIS remains set to 0 for a pin muxed to UART RXD, does this configuration cause no functional or electrical problems?
The TX_DIS pin is used to to disable the output driver when changing mux modes as detailed in the TRM, Table 14-13128, note 3.
To prevent unwanted glitches, software should disable the output driver by setting the TX_DIS bit before writing a new MUXMODE value. Once the new MUXMODE value is written, the TX_DIS bit can be reset in order to re-enable the pin driver.
When TX_DIS = 0, the output buffer enable is controlled by the peripheral selected by MUXMODE.
When UART RXD is selected, the output buffer will be disabled.

2. Where in the Technical Reference Manual (TRM) is it specified that using the UART RXD pin with TX_DIS = 0 (as configured in SysConfig “Debug Log”) is not an issue?
I would appreciate it if you could indicate the relevant chapter or section describing the control of the output buffer when the pin is muxed to a peripheral (UART RXD).
There is no TRM content covering the peripheral control of the output buffer. I will file a ticket to have this clarified in a future revision.

3.It is mentioned that keeping the output buffer ON “will draw a little current unnecessarily.”
If the UART RXD pin is muxed to the UART peripheral and the output buffer is automatically disabled by the peripheral, is my understanding correct that such unnecessary current consumption does not occur in this case?
This is correct. the output buffer will be disabled in the UART RXD case.

4.I would like to ask you to confirm the following point.
I understand that the TX_DIS setting is not effective when the MUXMODE is set to anything other than GPIO. Is my understanding correct?
This is not correct, the TX_DIS overrides any MUXMODE selected peripheral.

AM62P-Q1: Regarding UART RXD Pin Configuration (TX_DIS=0) in SysConfig “Debug Log” Section
1. Is it correct that there is no issue using the UART RXD pin configured in the SysConfig “Debug Log” section with TX_DIS set to 0?
In other words, even if TX_DIS remains set to 0 for a pin muxed to UART RXD, does this configuration cause no functional or electrical problems?
The TX_DIS pin is used to to disable the output driver when changing mux modes as detailed in the TRM, Table 14-13128, note 3.
To prevent unwanted glitches, software should disable the output driver by setting the TX_DIS bit before writing a new MUXMODE value. Once the new MUXMODE value is written, the TX_DIS bit can be reset in order to re-enable the pin driver.
When TX_DIS = 0, the output buffer enable is controlled by the peripheral selected by MUXMODE.
When UART RXD is selected, the output buffer will be disabled.

2. Where in the Technical Reference Manual (TRM) is it specified that using the UART RXD pin with TX_DIS = 0 (as configured in SysConfig “Debug Log”) is not an issue?
I would appreciate it if you could indicate the relevant chapter or section describing the control of the output buffer when the pin is muxed to a peripheral (UART RXD).
There is no TRM content covering the peripheral control of the output buffer. I will file a ticket to have this clarified in a future revision.

3.It is mentioned that keeping the output buffer ON “will draw a little current unnecessarily.”
If the UART RXD pin is muxed to the UART peripheral and the output buffer is automatically disabled by the peripheral, is my understanding correct that such unnecessary current consumption does not occur in this case?
This is correct. the output buffer will be disabled in the UART RXD case.

4.I would like to ask you to confirm the following point.
I understand that the TX_DIS setting is not effective when the MUXMODE is set to anything other than GPIO. Is my understanding correct?
This is not correct, the TX_DIS overrides any MUXMODE selected peripheral.

5. If “TX_DIS overrides any MUXMODE‑selected peripheral,” then when MUXMODE is configured to “UART RXD,” I would expect the UART to set TX_DIS=1. In my testing, however, TX_DIS remains 0. Could you explain why? Also, in your previous response you indicated that, even with TX_DIS=1, the output buffer would be disabled under this configuration. Could you please confirm whether this understanding is correct?
TX_DIS is an override control. IP's do not directly write to this bit, hence you do not see any change when selecting an input only signal via MUXMODE. Conceptually this is the setup..

Regards,

Sreenivasa

Hi Board Designers, 

Inputs regarding padconfig bits

The lock bit is used with the safety software.

Hi Board Designers, 

General design notes related to IOs

Characteristic Impedance at the input pin of an IC

Hi Board Designers, 

Queries related to GPIO grouping and supply connection:

Refer 6.3 Signal Descriptions for IO related to the DPI 

Table 6-9. DSS0 Signal Descriptions

The table lists all the signals used for DPI interface 

A number of LVCMOS IOs  are grouped together and a common supply for the group IO supply for IO group VDDSHVx is the supply referenced for the whole group.

Each of the IO supply group can be sourced by a fixed 1.8V or 3.3V supply.

Refer 6.2 Pin Attributes section of the data sheet for the GPIO information related to IO supply for IO group. 

The DPI signals (VOUT0_) are referenced to IO supply for IO group VDDSHV3

The IO buffer type is LVCMOS 

Refer below section for the specs

7.8.6 LVCMOS Electrical Characteristics

The IO levels is recommended to be above VIHSS or below VILSS.

The links to the data sheet and other collaterals are provided in the below FAQ

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1183910/faq-am625-custom-board-hardware-design-collaterals-to-get-started

Regards,

Sreenivasa

Hi Board Designers, 

Refer below for GPIO timing and slew rate 

7.11 Timing and Switching Characteristics

(+) [FAQ] AM623: MMC0 HS200 slew rate - Processors forum - Processors - TI E2E support forums

1) We only define Input slew rate for modes which have specific or fixed input timing requirements. The clock output to data capture time relationship is not fixed for the HS200 read data path since this mode requires data training. The data training algorithm used a known data pattern to select a data capture time that is centered in the data valid window. There is no specific input slew requirement since tuning searches across an entire bit time to find the center of the data valid window. However, the width of the data valid window is a function of input slew. The signal transition needs to be fast enough to provide a reasonable data valid window for the data training algorithm.

2) It is very important to limit the amount of time the applied signal spends within the voltage region between VIHSS and VILSS. The minimum input slew rate limits are required to ensure long-term reliability of the input buffer. 

The minimum slew of 1.8E+6V/s (1000ns when operating at 1.8V) is not a function of toggle frequency and it represents the slowest signal that can be applied to the AM62x input buffer. The minimum slew of 18fV/s (0.5ns when operating at 1.8V with a 200MHz toggle) is a function of toggle frequency and represents the minimum slew rate allowed for a specific operating frequency. The limit of 18fV/s is the more restrictive of the two limits, so this is the requirement to ensure long-term device reliability. In some cases, a specific peripheral may have a more restrictive requirement to ensure timing. 

 See Note 5 associated with the Input Slew Rate parameter, SR_I. The note defines which value applies by saying "Select the MIN parameter which results in the largest value".

The non-frequency dependent limit of 1.8E+6V/s becomes the larger value when the signal toggle rate is less than 100kHz. 

The frequency dependent limit of 18fV/s becomes the larger value when the signal toggle rates is greater than 100kHz.

The slew rate has frequency dependency.

1,8V mode

3.3V mode

A max slew of 1000ns is recommended when the signals toggle rate is not high (non-frequency dependent limit)

We basically need to limit the amount of time the input buffer is exposed to a mid-supply potential. The concern is related to the effect on reliable operation of the input buffer caused by shoot-through current that flows from VDD through the input buffer to VSS as the signal transitions through the mid-supply region. The slew rate limits ensure the device is not exposed to this condition for too long over the life of the board.

The risk associated with violating the limit is the possibility of the input buffer failing before the device POH limit.

We only care about the signal slew rate that is applied to an enabled AM62x input buffer.

The slew rate is not a concern for CLK signal as long as they turn off the associated input buffer with the respective RXACTIVE bit. This will not be possible for the IOs associated with the DAT/CMD signals since they are bidirectional. The external series resistor should provide some isolation from the load when AM62x is driving DAT/CMD, which should allow the signal to have a faster slew rate at the AM62x pin. We are only concerned with the signal slew rate on the AM62x pin since that is what is sourcing the AM62x input buffer. The external series resistor should not have a big impact on the signal slew rate at the AM62x pin when the attached device is driving DAT/CMD.

They need to be measuring the signal slew rate of the AM62x pin. Where are they measuring the signal slew rate?

The eMMC clock in AM62x is not looped back for retiming. AM335x did not have internal delay lines that could be used to optimize timing, so the clock was looped back at the pad to help compensate for the some of the delay inserted in the roundtrip time associated with read operations. It would not be possible to close timing for the faster data transfer rates supported in AM62x without having the internal delay lines. You do not need to loopback the clock once you have internal delay lines to compensate for external delays.

When you say they are measuring slew rate close to AM62x, are they probing on the actual device pin.  If not, the measured slew rate will not be the same that is seen by the AM62x input buffer. For example, the measured slew rate will have a 100ps mid-supply step include in the slew rate measurement if they probe the signal 0.3 inches from the AM62x pin. The mid-supply step gets shorter as you probe closer to the AM62x pin and gets longer as you probe further from the AM62x pin. The slew rate measurement is only accurate when probing the signal at the AM62x pin.

You mention competitor devices do not have similar slew rate requirements. This may be the case if these devices were implemented in a less-advanced process node, where the circuit geometries are larger. It may also be possible that competitors do not understand the risk associated with an input speeding too much time in the mid-supply region.

The mid-supply step will be equal to 2 times the PCB trace delay at the output buffer. The mid-supply step will be equal to zero at the input buffer connected to the far end of the PCB signal trace. The mid-supply step decreases from 2 times the PCB trace delay to zero as you move the probe from the source to the end of the PCB signal trace. The mid-supply step will persist for the time it takes the signal to propagate past the probe to the end of the PCB trace and return back to the probe. The average propagation velocity of a PCB signal trace is about 167ps per inch. In my previous example, probing 0.3 inches from the AM62x pin, it would take the signal 0.3x167ps = 50ps to travel past the probe to the end of the PCB signal trace, then it would take another 0.3x167ps = 50ps for the signal to return to the probe. This step will add 100ps to any rise/fall measurement, which can have a significant impact on measured slew rate.

There are multiple reliability concerns. One is aging, that causes propagation delay through internal circuits to degrade over time. The CLK output path and the DAT/CMD output path may not age at the same rate, which means one signal can get slower over time relative to the other signal. The timing closure team may have already accounted for the delay degradation associated with the different toggle rates, where they based the timing impact on our recommended min input slew rate. Violating the recommendation could cause timing violations over time.

It is going to be very difficult to analyze all of the concerns with violating the recommended min input slew rate. The customer needs to make an effort to meet our input slew rate requirements.

About Input Slew Rate of LVCMOS in Datasheet 

The min slew rate defined in the electrical characteristics defines the max transition time allowed for the signal sourcing the input buffer to prevent any long-term reliability concern which can occur if the applied voltage spends too much time in the mid -supply region defined by VILSS and VIHSS. This parameter is unrelated to timing requirements.

The min slew rate defined in the GPIO timing section defines the max transition time allowed for the GPIO minimum pulse width Timing Requirements to be valid.

I have two questions.

1.LVCMOS in IBIS model has two types, LVCMOS_H and LVCMOS_V.
Is the slew rate spec same both types?

2.You say slew rate of the electrical characteristics is related to reliability.
Is it same to all peripherals?

We have two layouts for each IO cell design, The ones with a "_V" suffix are implemented along the vertical edges of the die and the ones with a "_H" suffix are implemented along the horizontal edges of the die. The slew rate requirements are the same for both.

The slew rate defined in the Electrical Characteristics tables are a function of the IO cell reliability. The slew rates defined in the various Timing Conditions tables are a function of peripheral timing.

Propagation delay through input buffers will increase as the slew rate decreases. The effect of slew rate must be considered for short duration timing parameters. However, the RST3 parameter is not one of those short duration timing parameters. The slew rate influence on the RST3 parameter is not significant.

(+) AM3358: McASP rise time / fall time - Processors forum - Processors - TI E2E support forums

If the signal transitions too fast at the AM335x input pin, it can turn on the ESD cell which can sink a lot of current. If the signal transitions too slow it can remain in the threshold region for too long causing both P- and N-regions of the CMOS input buffer to shoot through, eventually affecting the processor internal logic implementation functioning (reliability concern) It is best to adhere to the datasheet requirements.

The transmission line on the PCB signal trace can take some of the edge off of fast rise and fall times. Recall a transmission line can is modeled with connected resistors, inductors, and capacitors which slow the edge rate down. The datasheet for the output buffer of the connecting device might have a rise/fall time that is faster than the Table 7-80 McASP Timing Conditions minimum timing, but the rise/fall time may be within range at the AM335x input pin. This can be measured or simulated with HyperLynx.

If the ESD cell turns on for a signal with rise/fall that is faster than the datasheet requirement, the signal will become distorted as the ESD clamp sinks lots of current.

(26) AM2432: IBIS Model - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

1. Looking into IBIS model(sprm730.ibs), there are two variations "LVCMOS_H" and "LVCMOS_V" for LVCMOS model. what's the difference between them?

The suffixes, _H and _V, refer to the orientation of the IO where _H is a horizontal orientation and _V is a vertical orientation. 

What are different LVCMOS_H with LVCMOS_V?

This references the layout orientation of the IO buffer on the die, H=Horizontal and V=Vertical.  

(+) [FAQ] TDA4VM-Q1: TDA4 Drive Strength Controls - Processors forum - Processors - TI E2E support forums

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1200155/faq-tda4vm-q1-tda4-drive-strength-controls 

        2. Looking into IBIS model(sprm730.ibs), it seems that there are six variations for LVCMOS_H (1.8V/3.3V x Nom/slow/Fast). Which one should I use for the simulation?

For the 1.8V vs 3.3V model, it depends on whether you plan to supply the IO supply VDDSHV<n> for IO group <n> with 1.8V or 3.3V. The datasheet lists each ball number's POWER. For example, The AM243x LaunchPad connects IO supply VDDSHV[0-4] to 3.3V supply and therefore all balls in the VDDSHV[0-4] power domain should be 3.3V models. 

Regards,

Sreenivasa

Hi Board Designers, 

Inputs related to GPIO ESD 

(+) [FAQ] AM2434: GPIO (pins) esd protection and maximum allowed voltages. - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Electrostatic discharge (ESD) protection circuits inside the processor are designed to protect the device from handling before being installed on a PCB assembly.

An external ESD protection is recommended to any of the processor IOs connected directly to an external connector or exposed to external inputs, because internal ESD protection circuit were not designed to handle the board level ESD requirements.

(+) Meaning : Min/Max of Clload (Output load capacitance) - Processors forum - Processors - TI E2E support forums

Meaning : Min/Max of Clload (Output load capacitance)

 I want to know the meaning of Min/Max Cload.   AM335x Datasheet said "GPMC Cload (Output load capacitance) is MIN 3pF, MAX 30pF" as follows.

 

 

 

 My understanding is that  when "the capacitor of between 3pF and 30pF" is attached on one of GPMC pins as the external load, AM335x can work under the datasheet timing.  Is it correct??  Please let me know. 

Yes, you are correct.  Timing parameters are verified with AM335x operating within the operating conditions defined in the Recommended Operating Conditions section of the data manual with a capacitive load in the range of 3 - 30 pF.

Regards,

Sreenivasa

Hi Board Designers, 

Inputs on GPIO propagation delay

(17) TDA4VM-Q1: Propagation delay for GPIO - Processors forum - Processors - TI E2E support forums

We are trying to measure/estimate the propagation delay from the TDA4 SoC to the Serializer (located on the camera). We have a GPIO connection between SoC and the Deserialzer. The latency between the time the application writes Logic High to be driven on one of the GPIO, to the time that the GPIO gets asserted is our area of interest

TDA4 --> Deserailizer -> GMSL Link --> Serializer --> Imager 

-------SoC---------------                               -------Camera--------

The latency between the time the application writes Logic High to be driven on one of the GPIO

If you are asking about the full latency from the time the application software sends a write request, that will likely vary depending on the initiator and software / system traffic, and thus not likely something we would be able to provide. 

regards,

Sreenivasa

Hi Board Designers, 

Inputs on LVCMOS input slew rate (MCU_PORz)

(+) [FAQ] AM625 / AM623 / AM620-Q1 / AM625-Q1 / AM625SIP: MCU_PORz input slew rate - Processors forum - Processors - TI E2E support forums

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.

A 22 pF glitch filter is recommended at the input of MCU_PORz

 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 AM625 datasheet is acceptable to the AM625 device but may not be acceptable for your system noise immunity requirements.

Please keep in mind the AM62x device requires the MCU_PORz input to have a maximum rise/fall time of 1000ns. This may be difficult to achieve with a pull-up on a signal sourced from an open-drain output buffer. You may need to buffer the open-drain signal with a push-pull buffer that has hysteresis on its input to ensure the AM62x device never receives a short reset pulse that violates the minimum pulse duration defined in the "MCU_PORz Timing Requirements" table. For example, it may be possible for noise to couple on the slow rising open-drain signal just as it crosses the input buffer threshold which could cause a short glitch on the reset signal. Normal device operation could be compromised if this occurs.

See the "Input Slew Rate" parameter in the "Fail-Safe Reset (FS RESET) Electrical Characteristics" table.

The MCU_PORz input is the only input on the AM62x device that is fail-safe and 3.3v tolerant. Therefore, you can pull the MCU_PORz signal to 1.8V or 3.3V.

See the "Steady-state max voltage at all fail-safe IO pins" parameter for MCU_PORz in the "Absolute Maximum Ratings" table.

Regards,

Sreenivasa

Hi Board Designers, 

Inputs regarding PADCONFIG register ST_EN bit configuration
We expect hysteresis to always be turned on for every input that is controlled by a PADCONFIG register.
The default state of the ST_EN bit, which controls hysteresis, is “1” in every PADCONFIG register.
This bit should not be changed to disable hysteresis.
Disabling hysteresis makes the device susceptible to internal glitches which can cause unpredictable problems."

Customer has now confirmed that GPIO event counting works correct once hysteresis is enabled on the pin.

The minimum Input Slew Rate parameter defined in each Electrical Characteristics table is associated with long-term reliability. These parameters are not a function of the ST_EN bit. Note: We never expected software to disable hysteresis on any of the input pins. 

The minimum Input Slew Rate parameter defined in each peripheral timing section is a requirement to meet the respective peripheral timing parameters.

The device may not work as expected if you violate the minimum input slew rate limit defined in the respective peripheral timing section, but the device could be permanently damaged if you violate the minimum input slew rate limit defined in the respective Electrical Characteristics table. It is very important that you minimize the time a signal connected to one of our input buffers spends in the mid-supply region as it transitions from low to high or high to low.

Several of the AM62x GPIO have an internal debounce circuit in their path to the GPIO module, which can be configured to filter a noisy signal. This would be a better solution than applying an external RC filter that slows the signal slew rate. See Note1 attached to each GPIO Signal Description table in the datasheet to know which GPIO inputs have the debounce feature. GPIO1_30 does not have the debounce capability.

What do you consider the best way to solve the issue in HW in future? Are our Schmitt Trigger gates providing sufficiently fast signals?

e.g. "The SN74LVC1G17 is a high drive CMOS device that can be used for a multitude of buffer type functions where the input is slow or noisy."

The Schmitt Trigger function (ST_EN) implemented in the input buffer only changes the output results of the input buffer, by filtering noise pulses that do not exceed the hysteresis.
The Schmitt Trigger function does not change how the input buffer is compromised when a system applies a slew rate to its input that is slower than defined in the datasheet.
The product must be designed to be in compliance with our datasheet requirements. If not, the non-compliance could reduce the life of the AM62x device.

The hysteresis was accidently turned off when this was never expected, but in reality, it has highlighted a system design error that violates the minimum slew rate allowed to the input buffer.

(+) [FAQ] AM623: MMC0 HS200 slew rate - Processors forum - Processors - TI E2E support forums

(+) [FAQ] AM625 / AM623 / AM620-Q1 / AM625-Q1 / AM625SIP: MCU_PORz input slew rate - Processors forum - Processors - TI E2E support forums

Please keep in mind the AM62x device requires the MCU_PORz input to have a maximum rise/fall time of 1000ns. This may be difficult to achieve with a pull-up on a signal sourced from an open-drain output buffer. You may need to buffer the open-drain signal with a push-pull buffer that has hysteresis on its input to ensure the AM62x device never receives a short reset pulse that violates the minimum pulse duration defined in the "MCU_PORz Timing Requirements" table. For example, it may be possible for noise to couple on the slow rising open-drain signal just as it crosses the input buffer threshold which could cause a short glitch on the reset signal. Normal device operation could be compromised if this occurs.

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.

Now I undesrstand the nRSTOUT for MCU_PORz must be less than 1000ns.

So I checked nRSTOUT. And it's rise time is 358.4ns. Fall time is 2.569ns . So they are OK.

Please keep in mind the AM62Ax device requires the MCU_PORz input to have a maximum rise/fall time of 1000ns. This may be difficult to achieve with a pull-up on a signal sourced from an open-drain output buffer. You may need to buffer the open-drain signal with a push-pull buffer that has hysteresis on its input to ensure the AM62Ax device never receives a short reset pulse that violates the minimum pulse duration defined in the "MCU_PORz Timing Requirements" table. For example, it may be possible for noise to couple on the slow rising open-drain signal just as it crosses the input buffer threshold which could cause a short glitch on the reset signal. Normal device operation could be compromised if this occurs.

See the "Input Slew Rate" parameter in the "Fail-Safe Reset (FS RESET) Electrical Characteristics" table.

The MCU_PORz input is the only input on the AM62x device that is fail-safe and 3.3v tolerant. Therefore, you can pull the MCU_PORz signal to 1.8V or 3.3V.

See the "Steady-state max voltage at all fail-safe IO pins" parameter for MCU_PORz in the "Absolute Maximum Ratings" table.

The VIL and VIH parameters are the traditional DC logic level thresholds, where the logic state will be low when the applied voltage less than or equal to VIL, high when greater than or equal to VIH, and undefined when greater then VIL and less than VIH.

The VILSS and VIHSS parameters are associated with device reliability, where any steady-state potential needs to remain below VILSS or above VIHSS to minimize the input buffers shoot-through current. The input buffer has a limited amount of time it can spend in the voltage region between VILSS and VIHSS without long-term reliability concerns. This is why the Electrical Characteristics tables define a minimum slew rate parameter that constrains the amount of time an input is allowed to be in this region. The amount of time a signal can be within this region is a function of toggle frequency, with a maximum upper bound of 1000ns for rise/fall times.

Regards,

Sreenivasa

Hi Board Designers, 

I couldn't find a way to configure that bit using our SysConfig tool. Is that a missing feature? 

Meanwhile got feedback from the SysConfig team:

Yes, we are currently working on adding multiple additional PADCONF settings in SysConfig in the future releases (including ST_EN and others see below list). Also these will come up depending on the register reset and how the pad is defaultly set. Again here is the list of new settings that will appear in the tool with per pin specific configuration at reset.

Groups (additional settings):
- WAKEUP:
WKUP_EN
WK_LVL_POL
WK_LVL_EN

- DSLEEP:
DS_PULLTYPE_SEL
DS_PULLUD_EN
DSOUT_VAL
DSOUT_DIS
DS_EN

- ISO:
ISO_BYP
ISO_OVR

Main (basic settings):
- PULLTYPESEL
- PULLUDEN
- RXACTIVE
- ST_EN
- DEBOUNCE_SEL
- DRV_STR

Regards,

Sreenivasa

Hi Board Designers, 

Refer input related to IO behavior during cold start

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1532561/am2432-the-gpio-external-10k-resistor-is-pulled-up-but-the-gpio-pin-level-is-not-monotonic-during-the-power-on-process

(+) AM2432: The GPIO external 10K resistor is pulled up, but the GPIO pin level is not monotonic during the power on process - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

 We found in our testing that multiple GPIO external 10K resistors of AM2432 were pulled up to VCCIO, which was 3.3V. However, during the power on process, the GPIO pin level was not monotonic. We synchronously tested the GPIO level and the VCCIO level when powered on together, as shown in Figures 1 and 2. The VCCIO level was monotonic, so this problem is not caused by the power supply. I have consulted a lot of information, and my conclusion is that many GPIO of AM2432 are in a floating state during the reset period and after reset release (but before software initialization), which makes the parasitic capacitance of the pins easy to cause interference during power on. Is my understanding correct? We hope TI can provide me with a more authoritative and credible explanation regarding this issue. Thank you!

Figure 1 and 2 GPIO Y7 test power up

Figure 3 and 4 GPIO V7 test power up

The IO cells implemented on pins Y7 and V7 were designed to operate at 1.8v or 3.3v mode. There is an internal supply detector mechanism that configures the IO in the appropriate mode based on the IO supply voltage level. During the mode transition from 1.8v mode to 3.3v mode or vice versa, it is possible for the IO to produce glitches on the signal. This doesn't cause any issue for the AM243x device.

You are correct. The IO cell monitors its own power rail and automatically changes from 1.8V mode to 3.3V mode as its IO power supply voltage continues to increase above 1.8V on its way to 3.3V. The opposite will happen as the IO power rail voltage decays. The IO cell will automatically change back to 1.8V mode as the IO supply voltage drops below 3.3V and approaches 1.8V.

The capacitor connected to pin L13 (CAP_VDDSHV5) doesn't have any effect on the IO cells associated with pins Y7 and V7, which are powered from pins R10, R8, and T9 (VDDSHV2). The glitch you see is not related to the value of any capacitor. It is a function of how the IO cell works. As mentioned in my previous post, there is nothing you can do to change how the IO cell works. However, connecting the wrong value capacitor can cause other problems.

Typically, a glitch on one of the AM243x pins is not an issue because the entire system is held in reset until all power supplies and clock sources are valid. You may need to insert a signal switch that blocks the glitch from propagating during power up if it is causing problems for your system.

(+) AM6421: AM6421 system: No firmware, VDD_CORE，VDDSHV_MCU and VDDSHV0-3 short - Processors forum - Processors - TI E2E support forums

You can get unpredictable results when measuring continuity of a power rail with a multimeter because the potential applied to the device by the multimeter can bias circuits in unpredictable ways. For example, the multimeter may trigger internal ESD protection circuits attached to the power rails.  If this happens the ESD circuits may think the potential applied by the multimeter is an ESD event, where the ESD circuits shunts current to ground.

The results of a continuity test can be misleading unless you power all of the power rails in the sequenced defined in the Power Supply Sequencing section of the datasheet with a ramp rate that is less than the max slew rate defined in the Power Supply Slew Rate Requirements section in the datasheet, and the potential applied never exceeds the voltage limits defined in the Absolute Maximum Ratings table.

Are you trying to measure continuity of the device power rails after it is installed on a PCB along with other components, or before the device is installed on a PCB? The multimeter may be measuring continuity through other components on the PCB if you are trying to make the measurement on an PCB assembly.

Have you tried applying power to the device to see if there is a problem?

(9) AM2431: Subject: AM2431BSDGHIALVR – VDD_CORE to GND Short After Assembly - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

We are facing an issue with the AM2431BSDGHIALVR (ALV 441-ball FCBGA package) during board bring-up.
Below are the detailed observations:

1. Before Assembly:

   • Bare PCB shows open impedance between VDD_CORE and GND.

   • New AM2431 device (unmounted) also shows no short between VDD_CORE and GND.

2. After Assembly (Board not powered On):

   • VDD_CORE and GND become shorted (0 Ω) immediately after reflow.

   • The PCB pads, after device removal, are again open (no short).

   • The removed device continues to show a permanent VDD_CORE–GND short.

3. Verification:

   • The short consistently appears only after reflow.

   • The affected pins are the VDD_CORE group (J10, J12, K11, K9, L12, L8, M11, M9, N10, N8, P9) surrounded by VSS balls under the die center region.

   • No power was applied to the board during or after reflow.

   • PCB footprint follows TI reference (solder mask defined pads).

We suspect a possible internal package-level short between VDD_CORE and GND occurring issue after assembly.

Please advise if:

• Whether this behaviour indicates a package reliability or MSL-related issue with this lot.

  
  

Please help us to resolve this issue. 

I’ve tested the board following the power-up sequence, and the VCC core voltage is now stable.

Regards,

Sreenivasa

Hi Board Designers, 

Refer input related to IO leakage

When power is supplied and PORz is not released unexpected voltage leaks to UART0_RXD pin.

The IO buffers for UART0_RXD are off during power-up.

A pull is recommended when a trace is not connected and a signal is not being driven actively.

Voltage on an unconnected AM62Px pin is possible. The voltage observed on the pin is the result of leakage paths in the IO buffer, where the leakage can be as much as 10uA to either VSS or VDDSHV. This is normal as long as the leakage is not greater than 10uA. The resulting mid-supply voltage is not a problem for the AM62Px device as long as the receiver (input buffer) in the IO buffer remains off. However, the pin must be driven or pulled to a valid logic level anytime the receiver is turned on. Never allow the input of an enabled input buffer in the AM62Px device to float.

Note: We recommend external pulls to be used on any signal that connects AM62Px to the input of another device. The external pull is needed to hold the signal in a valid logic state until software turns on the associated AM62Px IO buffer such that it drives the signal to a valid logic state.

There is a good chance the AM62x device has been damaged by an Electrical Over-Stress (EOS) event if the IO buffer has more than 10uA of leakage with the output buffer and internal pull turned off.

There is a good chance this device is implemented using a more advanced process node than any of your previous devices. The more advanced process node uses significantly smaller geometries to implement on-die circuits, where the transistors are much smaller and have higher leakage.

We expect the IOs of any attached device to be powered from the same IO power source that is powering the AM62Px IOs associated with the attached device. 

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.

The latest concern being discussed is a function of the power-down sequence and effect on the Ethernet PHY. However, there may be similar concerns associated with the power-up sequence and the effect on the AM62Px device.

The description seems to indicate the Ethernet PHY is powered from the same 3.3V power supply that is also sourcing the PMIC. If so, I suspect the Ethernet PHY receives power before the AM62Px device.  The Ethernet PHY may be applying potential to the AM62Px pins before they are powered. This would be the case if the Ethernet PHY has internal pull-ups that are turned on by default.

Regards,

Sreenivasa

Hi Board Designers, 

Refer input related to IO leakage

(+) AM625: I/O leakage current - Processors forum - Processors - TI E2E support forums

AM625: I/O leakage current

We only define one value for this parameter, and it is inclusive of all operating conditions.  We do not have additional data for specific operating conditions.

Please explain how this is creating a problem for your product design to see if I can offer any suggestions.

10uA is the limit for device pass/fall during final test, so there is a very small probability that you could get some devices that have up to 10uA of leakage. 

You may need to reduce the resistance of the pull-down to ensure the attached device is not enabled by the IO leakage.

Note: The more advanced process nodes have higher leakage due to the smaller transistors.

(+) AM625: CAN TXD leakage current - Processors forum - Processors - TI E2E support forums

What is the typ/max leakage current that I should expect from MCAN0_TX pin. 

The MCAN0_TX pin is implemented with a LVCMOS buffer type as shown in the datasheet Pin Attributes table. The leakage associated with the LVCMOS buffer type is +/- 10 uA as defined in the LVCMOS Electrical Characteristics section of the datasheet.

The next revision of the datasheet will have the following note added to the Input Leakage Current parameter to clarify its meaning.

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.

Data sheet section reference 

7.8 Electrical Characteristics

AM62P data sheet reference 

The same note will be added in the next revision of the AM625 data sheet 

FYI

(+) DRA829J-Q1: Internal Pull down structure - Processors forum - Processors - TI E2E support forums

Our application uses the DRA829J. Does the DRA829J use internal current sources or real ohmic resistors for its internal pull-downs?

We want to assure valid logic levels for the DRA829J.For example, our application connects the buffer 74LVC541A to the DRA829J.During normal operation the buffer 74LVC541A is high-impedant and the DRA829J has its internal Pull-Down (max. 30kOhm) activated. When calculating the maximum possible voltage level at this pin, which of the following approaches has to be used:

• "The leakage current of the high-impedant buffer times the 30kOhm" or"
• The leakage current of the high-impedant buffer plus the 10µA of the DRA829J-Pin times the 30kOhm"                                                                                                                                       

The latter approach would always lead to a minimum 10µA*30kOhm=0.3V at the Pin of the DRA829J. (Possibly worsened by e.g. our buffer)

The decision which approach to use should depend on the internal structure (either current   sources or real ohmic resistors)?

The processor enables a real ohmic resistor for its internal pull resistors.

the RPU values are also applicable for 3.3V mode.

Regards,

Sreenivasa

Hi Board Designers, 

Refer below for E2Es relevant to GPIO

(+) AM62D-Q1: The AM62D-Mcasp interface configuration - Processors forum - Processors - TI E2E support forums

Voltage on an unconnected AM62Dx pin is possible. The voltage observed on the pin is the result of leakage paths in the IO buffer, where the leakage can be as much as 10uA to either VSS or VDDSHV. This is normal as long as the leakage is not greater than 10uA. The resulting mid-supply voltage is not a problem for the AM62Dx device as long as the receiver (input buffer) in the IO buffer remains off. However, the pin must be driven or pulled to a valid logic level anytime the receiver is turned on. Never allow the input of an enabled input buffer in the AM62Dx device to float.

Note: We recommend external pulls to be used on any signal that connects AM62Dx to the input of another device. The external pull is needed to hold the signal in a valid logic state until software turns on the associated AM62Dx IO buffer such that it drives the signal to a valid

(+) [FAQ] AM625: I/O leakage current - Processors forum - Processors - TI E2E support forums

10uA is the limit for device pass/fall during final test, so there is a very small probability that you could get some devices that have up to 10uA of leakage. 

You may need to reduce the resistance of the pull-down to ensure the attached device is not enabled by the IO leakage.

Note: The more advanced process nodes have higher leakage due to the smaller transistors.

(+) TDA4VM: LVCOMS 3.3V MODE Output High Voltage - Processors forum - Processors - TI E2E support forums

VOH and IOH are output parameters -- the output can source 6mA and still maintain a voltage above 2.4V.

A pull-up is normally used when the pin is used as an input; in this case, the output parameters are not applicable. The leakage current is 10uA and IHL is 2V, so that (3.3V - 2V) / 10uA = 120K. Because of tolerances, I would tend to use a somewhat smaller resistor than 120K, but this is how I understand the math.

(+) DRA821U: Pin handling and leakage current - Processors forum - Processors - TI E2E support forums

(+) TDA4VM: ADC Leakage Current - Processors forum - Processors - TI E2E support forums

(+) AM625-Q1: I/O lines internal clamping - Processors forum - Processors - TI E2E support forums

So that means that except for fail safe io pins, the rest of Io pins have the clamping diodes. Based on this Article by TI, is this correct? Clamp diodes: A one-way street

Most of the AM62x pins have similar clamp diodes used to protect the internal circuits from ESD events withing the limits defined in the respective ESD Ratings table. The pins listed as fail-safe in the Absolute Maximum Rating use other circuit methods to implement ESD protection that doesn't have the same dependance on the potential applied to the IO power rail.

Note: The ESD clamps/circuits are only designed to protect the device during handling and assembly on a PCB. They were not designed to provide any system-level ESD protection. You must add external ESD protection circuits to any signal which could be exposed to ESD events after the AM62x device has been placed on a PCB assembly.

(+) AM2434: GPIO max current sourced/sink on AM24 - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

What is the GPIO current capability of the AM243

The explanation on GPIO is not part of the data sheet. Please refer to the TRM 

4.8 General Connectivity
4.8.1 General Purpose Input/Output (GPIO)

10.1.3 GPIO Interrupt Handling

12.2.1 General-Purpose Interface (GPIO)

According to the AM243x datasheet, the maximum current that can be sourced or sunk by a single GPIO pin is typically:

 4 mA for low-drive strength, 8 mA for medium-drive strength, 12 mA for high-drive strength, Can you please confirm

AM62A7-Q1: Interrupt Capable GPIOs ?

The AM243x datasheet only defines a single data point for current source/sink capability to achieve a specific output voltage (VOL or VOH) in the respective Electrical Characteristics section of the datasheet. The system designer will need to use the device IBIS model to determine the output voltage for any load other than the values defined in the IOL and IOH parameters.

Note: We only expect our digital output buffers to source CMOS inputs which have a minimum amount of leakage current when driving a steady-state logic level. We do not expect our digital outputs to drive any significant steady-state current.

See the table note associated with the IOL and IOH parameters.

Regards,

Sreenivasa

Hi Board Designer,

May i know what is the period for functional clock as specified in GPIO timing requirement?

Refer below:

HFOSC0_CLKOUT -- This is the HFOSC placed on the board. Usually 25 MHz for Sitara SoC boards.
MAIN_SYSCLK0 -- 500 MHz (Derived from MAIN PLL 0 and this is not allowed to be changed in DM firmware)
MCU_SYCLK0 -- 400 MHz (Derived from MCU PLL 0 and this is not allowed to be changed in DM firmware)

For other clocks, the defaults can be found here

AM62PX PLL Defaults — TISCI User Guide

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62px/pll_data.html

Note: You need to use the Clock tree tool to get the clock period for each peripheral where the functional clock period is reference.

Regards,

Sreenivasa

Hi Board Designer,

Inputs related to max frequency:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1551807/am6442-signal-frequency/5975519

Can you help me to find the max. frequency for I2C, SPI, UART and GPIO's signals of the AM6442 processor

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1549638/am620-q1-input-slew-rate/5966524?tisearch=e2e-sitesearch&keymatch=MAIN_SYSCLK0#

Regards,

Sreenivasa

Hi Board designers,

Refer below interaction on floating IOs

AM62A3-Q1: Floating voltage of the G21 pin at startup

Voltage on an unconnected AM62Dx pin is possible. The voltage observed on the pin is the result of leakage paths in the IO buffer, where the leakage can be as much as 10uA to either VSS or VDDSHV. This is normal as long as the leakage is not greater than 10uA. The resulting mid-supply voltage is not a problem for the AM62Dx device as long as the receiver (input buffer) in the IO buffer remains off. However, the pin must be driven or pulled to a valid logic level anytime the receiver is turned on. Never allow the input of an enabled input buffer in the AM62Dx device to float.

Note: We recommend external pulls to be used on any signal that connects AM62Dx to the input of another device. The external pull is needed to hold the signal in a valid logic state until software turns on the associated AM62Dx IO buffer such that it drives the signal to a valid logic state

At the start-up of the SoC, a floating voltage of about 100mV is observed on pin G21. Is this normal operation? Why is it floating?

Ether PHY supplier says maybe there is PU(min 30k / max150k)

If so, we can understand why 100mV floating voltage happens at Ether PHY side by following our calculation.

Could you please add a pulldown on the SOC output pin without connecting to the EPHY reset input 

The result is there is no floating voltage. So, I have confirmed that it is as you explained.

So, now we understand why floating voltage happens at SoC and Ether side.

Regards,

Sreenivasa

Hi Board designers,

Refer below information related to:

Debounce support

Data sheet reference:

Signal Descriptions section

At the end of the peripheral signal description, debounce support is mentioned.

Pin Attributes

Hysteresis

HYS: Indicates if the input buffer associated with this I/O has hysteresis:

• Yes: With hysteresis

• No: Without hysteresis

• An empty box means Not Applicable.

(+) AM62A7-Q1: set the port as gpio for am62a - Interface forum - Interface - TI E2E support forums

Regards,

Sreenivasa

Hi Board designers,

Refer below information related to pin attributes:

Pin Attributes
The following list describes the contents of each column in the Table 6-1, Pin Attributes (AMH Package) table:

BALL STATE AFTER RESET RX/TX/PULL:

But TX (Output buffer) status of some ball are "SS".

SS means "the subsystem selected with MUXMODE determines the output buffer state".

Where can i find the description of the each subsystem behavior 

We do not define the operation of device subsystems in the datasheet. The datasheet provides the minimum amount of information that is necessary to define electrical and timing information. Descriptions of how a specific subsystem operates needs to be/is included in the TRM.

Regards,

Sreenivasa

.

Hi Board designers,

AM623: Timing WKUP_CLKOUT0

My customer wants to use WKUP_CLKOUT0 for an external Wifi device.

Taking the power-up sequence as a reference by when is it stable and ca be used?

This IO cell associated with this pin will not be turned on until MCU_PORz has been released, reset propagates through the device, and enables the IO. This time is not defined, but it should be very soon after the rising edge of MCU_PORz.

Note: The first clock cycle may be short or a glitch since the IO buffer is being turned on asynchronous to the clock. Any device using this clock needs to be held in reset for a few clock cycles after the IO turns on to ensure the attached device is not over-clocked by a short cycle.

MCU_CLKOUT0, CLKOUT0 and AUDIO_EXT_REFCLK[1:0] are the only clock output signal functions that can be used to source external devices.

MCU_CLKOUT0 can only be configured to source a 25MHz or 50MHz clock. This optional clock source must be configured by software, and was primarily provided for clocking an Ethernet PHY, 

CLKOUT0 will begin sourcing the AM62x 25MHz reference clock as soon as the device is released from reset (MCU_PORz 0->1). This clock source was primarily provided for clocking an Ethernet PHY,

AUDIO_EXT_REFCLK[1:0] signal functions were provided as optional clock sources for audio devices. I'm not familiar with the McASP module that sources these signal functions, so I'm not sure if it could be configured to source a 10MHz clock. I suggest you read the McASP information in the TRM to see if it can be configured to source a 10MHz clock on one of these signals. You may want to reference the following E2E thread to see if it helps answer your question.

(+) PROCESSOR-SDK-AM62X: Output AUDIO_EXT_REFCLK0 as MCLK for codec and mcbsp - Processors forum - Processors - TI E2E support forums

Note: TI does not define performance of the AM62x clock outputs because clock performance is influenced by many variables unique to each system implementation. You should plan to validate any clock output is able to meet the appropriate level of performance required by the attached device using your actual system design while operating across all operating conditions.

Regards,

Sreenivasa

Hi Board Designers, 

Inputs related to processor behavior when processor power is applied and external voltage is applied 

Please refer to the below section of the data sheet.

6.1 Absolute Maximum Ratings

Power supply pins

processor IO pins 

IO buffer type IOs

LVCOMOS and SDIO buffer type IOs are not fail-safe. 

I2C OD FS buffers are fail-safe IOs.

The specs are listed in the above picture.

Can you verify the external voltage level applied when the processor is not connected.

If the voltage applied is more than 0.3V for extended duration, an external protection is recommended.

Note: In case there external voltage applied is higher that the Absolute Maximum Ratings there will be a residual voltage on the supply rails that can affect the board functionality.

Regards,

Sreenivasa

Hello Board Designers. 

Inputs related to MCU_CTRL_MMR_CFG0_IO_VOLTAGE_STAT

AM62L

AM64x

AM62x

AM62A

Regards,

Sreenivasa 

Hi Board Designers,

Inputs related to GPIO state and IOs

AM62P data sheet mentioned that BALL STATE AFTER RESET Tx = SS means "the subsystem selected with MUXMODE determines the output buffer state".But I couldn't find the output buffer state of each subsystem on the Technical Reference manual and Data Sheet.Could you please let me know where these are mentioned.

I want to know about the following balls.
- PMIC_LPM_EN0
- TDO
- WKUP_CLKOUT0
- MCU_RESETSTATZ
- RESETSTATZ
- PORZ_OUT

The PMIC_LPM_EN0 pin requires an external pull-up to the VDDSHV_CANUART power source. The pin will be high-Z during reset, which allows the pull-up to turn on the PMIC as soon as the always on VDDSHV_CANUART supply ramps up. The pin will be driven high once the device is released from reset (rising edge of MCU_PORz). It will remain high until the device has been put into CANUART mode and told to enter deep-sleep, where it is driven low to turn off the PMIC. It will be driven high once again when the CANUART detects an external wakeup event.

The operation of the TDO pin will be compliant to the IEEE-1149 specification after the device is released from reset (rising edge of MCU_PORz).

The WKUP_CLKOUT0 pin will be driven low after the device is released from reset.

Each of the three reset outputs in question will continue to be driven low for a short period of time after the device is released from reset (rising edge of MCU_PORz). Please refer to the Reset Timing section of the datasheet to understand how long each of these signals remain low relative after the rising edge of MCU_PORz.

The value in the "MUX MODE AFTER RESET" column of the Pin Attributes table defines the default mux mode. The signal function associated with the default mux mode will be automatically selected after reset. The respective subsystem that is sourcing the default signal function will determine how the pin operates. Each of the six pins you asked about will default to a signal function that is an output, where their respective subsystem source will determine if the output is driven low, driven high, or undriven (high-Z). I have explained the initial state for each of these pins in my previous post. Three of the six pins support another signal function, which can be changed by software after the system has booted. If these pins were reconfigured to use their secondary signal function, the circuit attached would need to tolerate whatever the default signal function does to these pins before they are reconfigured by software.

Regards,

Sreenivasa

Hi Board Designers,

Inputs related to GPIO input slew

(10) AM2431: Total amount of time allowed for a signal within the range between VILSS and VIHSS for GPIO - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

The max rise/fall time allowed for a signal with a toggle rate that is less than 100kHz, is 1000ns measured from the respective IO’s VILSS and VIHSS values.  The falling edge appears to be slightly over the limit when measured from 10/90, but may be okay if measured VILSS/VIHSS.  The rise time is not even close.  They may need to buffer the signal with push-pull driver before sending into our device.

All four pins use LVCMOS buffers so they should measure rise/fall times based on LVCMOS VILSS/VIHSS values.

We do not define a total time, we only define two long-term reliability limits for minimum input slew rate.  One is non frequency dependent, where this limit is equivalent to a maximum rise/fall time of 1000ns and only applies for signal toggle rates equal to or less than 100kHz.  The other limit is frequency dependent, where this limit is a function of signal toggle rate and applies for signal toggle rates greater than 100kHz.

Regards,

Sreenivasa

HI Board Designers,

Inputs related to connection of the push button to SOC IO and need for external ESD protection

Option 1:

You may want to move the switch connecting to pin  B12 to one of the other pins that has the hardware debounce function on its GPIO.  This could potentially prevent from having to do a software debounce of the switch. The GPIO associated with pin C11 has the hardware debounce function.

The SOC GPIOs supporting hardware debounce is included in the below section

Data Sheet section reference

5.3 Signal Descriptions

5.3.10 GPIO

5.3.10.1 MAIN Domain

(1) This GPIO input signal has a debounce function. For more information on I/O Debounce configuration, see the TRM Device
Configuration chapter.

TRM section reference 

6.1 Control Module

6.1.2 I/O Debounce Control Registers
Some device pads have debounce logic. The following MCU_CTRL_MMR0 registers are used to configure the
debounce period:
• MCU_CTRL_MMR_DBOUNCE_CFG1
• MCU_CTRL_MMR_DBOUNCE_CFG2
• MCU_CTRL_MMR_DBOUNCE_CFG3
• MCU_CTRL_MMR_DBOUNCE_CFG4
• MCU_CTRL_MMR_DBOUNCE_CFG5
• MCU_CTRL_MMR_DBOUNCE_CFG6

Option 2

Adding external debounce cap across the switch

I do not see any cap added to the switch connected externally for debounce. Trying to understand internal SOC debounce logic suffice. I suspect the debounce time can be configured.

A capacitor should not be needed when using the hardware debounce function.  There is some programmability,  refer to the TRM to get the details.

 The recommendation is use a buffer between the switch and our input when using a capacitor because we do not allow a rise/fall longer than 1000ns and switch bounce is very likely to last longer than 1000ns.  So using a capacitor alone is not a valid solution.

The buffer used on a capacitor debounced switch should have a Schmitt trigger input that provides hysteresis to the input switching threshold.

Refer SK schematics for implementation.

Additional inputs regarding external ESD protection

All processor signals which come in close proximity of a human touch should have ESD protection.  It helps to use a shielded switch, but I would still recommend ESD protection on any signal connected to a switch that can be operated by a human.

Regards,

Sreenivasa

HI Board Designers,

Inputs related to LVCMOS IOs

I see the below app note on AM62x, AM62Ax, AM62Px, AM64x, AM243x and AM67xproduct page.

 Is this application note applicable only for LVCMOS IOs like OSPI, DPI and RGMII?

Correct. The intent is to provide customers guidance for all 16FF devices which employ the dual voltage 16FF LVCMOS IOs.

Regards,

Sreenivasa

Hi Board designers,

FYI on supply slew and internal ESD 

(+) AM6548: Confirmation on slew rate - Processors forum - Processors - TI E2E support forums

Per the datasheet for the AM6548, the maximum slew rate is recommended to be less than 100 mV/µs for supplies in general, and less than 40 mV/µs for the VDDA_1P8_SERDES0 supplies. Alternatively, the slew time must be greater than the supply value x 10µs, and greater than supply value x 25µs, respectively.

Just to confirm, this slew rate does apply for both rise and fall times?

The max power supply slew rates requirement defined in the datasheet only applies when the power rails are ramping up. The ESD circuits implemented on the power rails may false trigger, clamping the power rails to VSS if the power rails ramp too fast.

Are there any requirements on the slew rate for fall times?

No.

Additional inputs:

The power supply slew rate is only defined for power-up. This slew rate limit is required to prevent the ESD circuits implemented on the power pins from accidently triggering. 
We expect MCU_PORz to be applied before any of the supplies begin to drop.  MCU_PORz signal not reaching a valid logic low level before the supplies begin to ramp down may allow unexpected things to happen on peripheral pins as power supplies decay.

Additional references

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1533771/am6421-am6421-system-no-firmware-vdd_core-vddshv_mcu-and-vddshv0-3-short/5903040 

(+) AM2431: Subject: AM2431BSDGHIALVR – VDD_CORE to GND Short After Assembly - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Do all I/O lines of AM62A3 have internal clamping diodes to ground and Vcc?

I would like to know all IO buffer configurations in detail. The following description is insufficient.

Clamp diodes are used on most IOs, but not all of them. The fail-safe pins mentioned in the Absolute Maximum Ratings table will not have clamp diodes.  These pins have a more complex ESD protection circuit that shunts current to VSS if the signal ramps too fast or the potential goes above a safe limit.

Note: The ESD protection circuits implemented in the AM62Ax device were only designed to protect the device during handling and PCB assembly. External ESD protection devices are required to protect the AM62Ax device from system-level ESD events after it has been assembled on a PCB.

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.

Additional Inputs

1. What happens to the CPU if our board doesn't follow the power sequence ( Power-Up Sequencing and Power-Down Sequencing)?
There could be long-term reliability concerns due to current flowing through unexpected paths if the proper power-up/power-down sequence is not followed.
2. What happens if the power supply fluctuates within the range of Power Supply Slew Rate Requirement?
SectionPower Supply Slew Rate Requirement defines a single limit rather than a range. Internal ESD protection circuits on the power pins may trigger if the power supply voltage increases faster than the limit defined in Power Supply Slew Rate Requirement section. When this occurs the ESD circuits will try to shunt current to VSS which will cause the power supply pins to draw much higher current than normal.
3.Behavior of IO pins during power supply ramp.
The state of IO pins are not known until all power supplies are valid and reset has asynchronously propagated through the device.
Most IO pins default to a safe state where the output buffer, input buffer, pull-up, and pull-down are turned off until software changes it's configuration. However, this state is only valid after all power supplies are valid and reset has asynchronously propagated through the device. The default state of the pins while reset is asserted and after reset is released is defined in the Pin Attributes table in the datasheet. The state of pins may change again after the ROM boot code is executed. The processor-specific TRM should define which pins are used by the ROM boot code for each boot mode.

(+) AM625: AM6254 power up sequence question - Processors forum - Processors - TI E2E support forums

Will the external circuit(e.g SPI slave side) influence the AM6254 power up sequence? i mean if the SPI or other communication interface(slave side) power up first, will it introduce some current into the AM62 and mess up the AM62 power up sequence? 

Many of the AM62x pins are not fail-safe and they should not have any potential applied until their respective power rail has ramped to a valid level. For more information refer to the Absolute Maximum Ratings and Recommended Operating Conditions tables in the datasheet.

Regards,

Sreenivasa

Hi Board designers,

FYI on pin connectivity

(+) 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.

Regards,

Sreenivasa

Hi Board designers,

FYI inputs on supply voltage related behavior

The recommended supply voltage range for AM62P is 3.3V is defined as below.
If out of this range, is it mandatory to reboot the power supply?
Or is it OK to just reset?

Please refer to the below section of the data sheet.

Please refer below FAQ to refer to the latest revision of the data sheet.

 [FAQ] AM625 / AM623 / AM620-Q1 / AM62L / AM62A / AM62P / AM62D-Q1 / AM64x / AM243x Design Recommendations / Custom board hardware design - Current Data sheet revision, updates, revision backup and usage notes 

Regards,

Sreenivasa

Hi Board designers,

FYI inputs on GPIO behavior during reset.

I need your help with the point below in the AM64X TRM.

Use case: isolating the MCU core from the MAIN  domain.

In the AM64X 5.3.5.2.2 chapter, we say that MAIN IO's are not affected by the reset isolation method.

Here, I am trying to understand: How can we isolate IOs during a reset? Do we need to follow any steps to achieve this?

Or without any steps by default, we should achieve these steps once we isolate the MCU core from the main domain.

IO here refers to Pinmux and Padconfig settings (Such as mux mode, pull up/down controls, RX/TX active/disable controls etc.) controlling the IO buffer. During warm reset these are not reset. However, when you assign a pin to a certain module, in this case GPIO, when Main domain gets a warm reset event, it will reset the GPIO module. If you previously configured GPIO module as an output it will go back to reset state (which is input).

 If you need GPIO pin to not reset on main warm reset, then you will have to use MCU GPIO and enable MCU Reset Isolation.

Regards,

Sreenivasa

Hi Board designers,

FYI, Example PAD config register 

AM62Px Sitara® Processors

14.2.1.2 Pad Configuration Registers
14.2.1.2.1 Pad Configuration Register Functional Description

DRV_STR

Drive Strength Control. Selects the drive strength value for LVCMOS pins. (Does not
apply to other pin types)
0h - Nominal
1h - Reserved
2h - Fast
3h - Reserved

Note:

The nominal (default) DRV_STR settings should be used to ensure timings,
unless specific instructions are given otherwise.

Summary of Pad Configuration Registers

14.2.1.2.2 Pad Configuration PADCONFIG Registers
Table 14-13129. AM62P PADCONFIG Registers

Regards,

Sreenivasa

Hi Board designers,

FYI, Example PAD config register AM62Lx Sitara® Processors (to understand the changes in the PAD config bits)

Regards,

Sreenivasa

Hi Board designers,

FYI, AM62A3-Q1: Maximum current flowing during a terminal short

When the internal pull-up is not set and the terminal is shorted to GND, what is the maximum current that will flow?

Is there a current-limiting resistor inside the AM62A?

 Per the AM62Ax datasheet, SDIO Electrical Characteristics section, footnote (3), the IOH/IOL specify the minimum output current for which the device can still maintain the specified VOH/VOL, and those values should be treated as the maximum current you need to maintain valid logic levels, not as a max short current.

We do not define a max current because this is not a valid use case for the device. If this short occurs, it would be considered an Electrical Overstress (EOS) event that could damage the device. You must prevent this from happening. 

There is no data on the current value when a short occurs because driving an output into a short is not valid operating condition and can damage the device.

The IOH/IOL values are for maintaining VOH/VOL logic levels.

Regards,

Sreenivasa

Hi Board designers,

E2Es for reference related to Series or Parallel termination for IOs or peripherals 

GPIO

 TDA4VE-Q1: Input Low Voltage SPI connection to LVCMOS pin 

So, according to the datasheet, their maximum low-state voltage is 0.6 or 0.8V.

When using these pins for SPI communication, should we use a maximum value of 0.8V, or should we treat SPI as a steady state?

This steady state spec is related to reliability, and is meant to address what strength of PU or PD is used on a signal.  For basic functionality, the VIH and VIL defines the logic high and logic low level during active operation.

 AM4372: Sink current of AM4372 EXTINTn pin at high temperature 

Does the sink current in the AM4372's EXTINTn pin increase at high temperature?

When turning on the board when the device temperature is about 80 ℃, this pin on my customer's board will only rise up to about 1V.

The circuit and wave form are as follows.

 AM6442: Specification of output voltage of LVCMOS 

The max limit defined for VOL is valid as long as the IOL is less than 3mA, and the min limit defined for VIH is valid as long as the IOH is less than 3mA.

The datasheet is saying the output buffer is able to sink current up to the min IOL current of 3mA and the low-level output voltage will remain less than the max value of 0.45V defined for VOL, and the output buffer is able to source current up to the min IOH current of 3mA and the high-level output voltage will remain greater than the min value of (VDD - 0.45V) defined for VOH.

 RE: AM3354: LVCMOS pin low-level output voltage 

The VOL maximum value published in the AM335x data sheet is compliant to the JEDEC specification. A JEDEC compliant device should have a VIL maximum value of 0.35 VDD when operating at 1.8 volts. So the NAND device should have a VIL maximum value of 0.63 volts to be JEDEC compliant.

 [FAQ] AM6442: How does LVCMOS buffer behavior 

The output buffer will source current from the respective VDD IO power rail to the external connections when driven high, or sink current from the external connections to VSS when driven low. The signal voltage will depend on the source current or sink current. The only data point we define in the datasheet is for current up to 3mA, where the signal voltage will remain less than the max VOL value of 0.45V as long as the sink current is less than 3mA, and the signal voltage will remain greater than the min VOH value of (VDD - 0.45V) as long as the source current is less than 3mA. The internal voltage dropped across the output buffer will decrease as the current decreases. A typical LVCMOS input buffer only has a few uA of input leakage current that needs to be driven by the output buffer to hold a valid logic state. There is a good chance external pulls, internal pulls, or combinations of external and internal pulls will present a much larger load than all attached input buffers.

We provide an IBIS model of the output buffer that can be used to determine the resulting signal voltage for operating conditions not defined in the datasheet.

You will need to create a simulation environment that represents your specific implementation and use the IBIS files of each device to determine the steady-state signal voltage for your specific system implementation if you are connecting a device that requires a logic high signal voltage that is greater than the min VOH value of (VDD - 0.45V) or a logic low signal voltage that is less than the max VOL value of 0.45V.

 RE: AM3357: Max capacitance GPIO can drive 

The IO were not designed to drive a large capacitive load and we have never evaluated the effects on the IO cell’s long-term reliability when driving an IO with a 1nF load.

(+) AM69: Terminating IO pins and using internal pull resistors - Processors forum - Processors - TI E2E support forums

For the pins types you listed, yes external pull resistors are required to avoid any window where the state of the pin could be unknown/floating (and RX is enabled).  You question 'for all other pins can be left open'.  You should refer to Section 6.4 Pin Connectivity Requirements for information on connecting all IO types if unused.

Setting of the IO padconfig registers is immediate - however if pin is low and pulling up with internal resistor, the change in pin state is not immediate.  You could use the resistor value (for LVCMOS pull resistor is 15K - 30K) and IO capacitance would be defined in the IBIS model.  A worst case value could be calculated.  However - if you are disabling RX and pin is unused...there is no need to re-enable the RX buffer.

e2e.ti.com/.../716606
You must not violate the "Steady State Max. Voltage at all IO pins" requirement of "-0.5V to IO supply voltage + 0.3 V"which can be found in the Absolute Maximum Ratings section of the AM335x Data Sheet. Therefore you should not apply pull-ups before the respective supply voltage.
e2e.ti.com/.../2391954
If the customer has units in the field with this problem, the C6748 component may be damaged. There isn't anything that can be done with software to prevent this problem from occurring. I don't have any work around for existing boards that did not follow the errata.
e2e.ti.com/.../5041220
e2e.ti.com/.../5691983
e2e.ti.com/.../5954039
e2e.ti.com/.../6093980
e2e.ti.com/.../6207488
e2e.ti.com/.../5766092
e2e.ti.com/.../2136756
The state of any IO buffer is unknown until all power supplies are valid. So it is possible for the IO buffer to be enabled and driving an undetermined logic level to the pin during the power on sequence.
e2e.ti.com/.../5381691
This is not an expected use case for the AM335x device. We never validated any DC current over 6mA, so I’m not able to say what will happen during this condition. There is a chance the device appears to works as expected after this condition, but the IO and the on-die connectivity may be damaged such that it creates what we call a walking wounded device that may experience an issue with long term reliability.
If the concern is with product reliability, the recommendation is to use a bus FET switch configured such that it ensures only one clock source is connected to the signal.

 AM4372: Capacitor value connectable to LVCMOS pin 

 [FAQ] AM6442: AM6442 LVCMOS Buffer Type 

The Electrical Characteristics tables defines capabilities of a specific IO cell. It does not define a how the IO is configured to operate. You need to reference the Pin Attributes table to understand how the IO associated with each pin is configured to operate. For example, the AM64x RESETSTATz signal function is implemented such that it is "Off / Low / Off" while MCU_PORz is asserted and "Off / SS / Off" after MCU_PORz has been de-asserted. This indicates the input buffer associated with the RESETSTATz pin is turned off during and after reset. The output buffer associated with the RESETSTATz pin is enabled during and after reset, where the output is actively driven low during reset and controlled by the reset subsystem after reset. The internal pull resistors associated with the RESETSTATz pin are turned off during and after reset.

In summary the RESETSTATz pin is an always enabled output only pin, where Vol, Voh, Iol, and Ioh are the only parameters defined in the LVCMOS Electrical Characteristics table that applies to the LVCMOS IO that is being used to implement the RESETSTATz pin.

e2e.ti.com/.../am3352-internal-pullup-pulldown-resistor-tolerance
e2e.ti.com/.../am5728-pullup-pulldown-questions
1. The resistor value can be calculated according to Ohm's law:
Rpulldown = VDDSHVx / IIN with pulldown enabled
Rpullup = VDDSHVx / IIN with pullup enabled
2. After the pin is configured by software, except in cases where the pullup/pulldown is enabled at reset release time. See Table 4-2 in the datasheet.
3. Yes, but there is normally no need to enable it.
e2e.ti.com/.../4081600
e2e.ti.com/.../902555
You need to consider the worst-case internal leakage current possible for each IO and size your external resistors such they will be able to pull the signal above or below the valid logic levels defined for the respective IO. If other devices are attached, you may need to add their internal leakage to the AM335x internal leakage when calculating the maximum resistor value required to pull the signal to the worst-case valid logic level of all attached devices.
e2e.ti.com/.../am3358-reason-for-some-gpios-connected-together
Normally this type of arrangement would be used to allow either one or the other of the SoC pins to be connected to the expansion connector.
e2e.ti.com/.../am5728-state-of-io-pins-when-power-is-not-applied-to-am5728
The IO signals of the SoC must not have an active voltage applied while the SoC is not powered. This can damage the device.
Generally any PU voltage on a given IO should be from the same rail that is powering that SoC IO. In this case it's VDDSHV3:
The IO is effectively grounded when IO power is not on. The PD is not active.
e2e.ti.com/.../3591355
The AM335x device was not validated for IO output currents greater than 6mA. Any current greater than 6mA would be considered an Electrical Over-Stress (EOS) condition and may damage the IO.
There is a reasonable chance the IO would not fail if the 22mA load is only applied for a short period of time. However, loads greater than 6mA were not validated by the IO design team. Therefore, it is not possible for TI to provide any long term reliability data associated with this EOS condition.
A 6mA drive current is primarily provided on these IOs to transition the signal state from low-to-high or high-to-low to achieve acceptable timing margin as defined in the respective timing sections of the datasheet. The AM335x IO were not expected to drive steady-state loads. However, they should be able to source 6mA without any issue.
e2e.ti.com/.../linux-am3352-activation-of-internal-pullup-pulldown-for-outputs
If there are no other design considerations to take into account, then users can save power by disabling pull resistors for output only pins. However, there may be other factors, especially in non-battery powered systems. For example, a pull resistor may enforce a default state on the output pin during startup and low power modes without requiring extra programming. In general, we encourage users to enable pull resistors based on their system requirements, and disable pull resistors only if their design does not call for pull resistors to be enabled.

Sometimes, the power savings from disabling pull resistors is insignificant. If an output signal is typically high or typically low, then we wouldn't expect a pull resistor in the direction of that typical value to draw significantly more power.

e2e.ti.com/.../am3358-gpio-maximum-current-rating

e2e.ti.com/.../am572x-i-o-pullup-pulldown-resistor-value
Internal pull-up/pull-down resistors are implemented with weak transistors. As the voltage present on the I/O pin varies the relative gate voltage to this weak transistor changes which will cause the effective pull-up/pull-down resistance to change. Therefore, internal resistors do not have a linear response like external resistors. The none-linearity along with process voltage and temperature variations require internal pull-up/pull-down resistors to be specified with a wide range of resistance or current sourcing/sinking.

The input current defined without a pull-up or pull-down turned on is for input leakage without any current from the internal pull resistors. The input current defined with a pull-up or pull-down turned on is a combination of leakage current and the current required to force the internal pull resistors to the opposite voltage rail. For example, if an internal pull-up is turned on the value shown represents the total current required to pull the input to VSS.

When deciding what value of external resistor to use you must consider the worst case combination of all internal leakage paths of all devices connected to a signal and make sure the external resistor is able to force these internal leakage paths to a potential greater than Vih min, or less than Vil. You must insure the input is not held at a mid-supply potential for long periods of time.
e2e.ti.com/.../3473709
Following is our schematic, since the power supply for GPIO5_8 is 3.3V (VDDSHV3=3.3V). So, we guess it may be a risk. how's the risk level?
Our product will released soon, we want keep the design and evaluate the risk. Yes, you are violating the absolute maximum voltage rating of the IO, which will eventually stress the IO to the point of failure. I would say the risk is high, but the time to failure will differ from device to device. The schematic did not paste correctly. Is there any way you can remove to pullup and still function properly? I think this would be your only option with the current design.
I want to have more discussion with you about this pull up voltage, I pasted the schematic again hope you can see it.

From the schematic you will see the signal of AC_DETECT is pull up to 5V through a 10k resistor, and the MOSFET works as turn on/turn off of the AC-DETECT, we measured the voltage of AC_DETECT on our board during MOSFET OFF, it is about 3.568V, not exceed 3.6, from the datasheet of AM4376, it doesn't exceed the maximum voltage rating but very very close to it.

Can you explain why the voltage is 3.568V, not 5V?
And the current is very small 5V/10K less than 0.5mA, do you think this current level still have high risk of CPU IO? if yes, can you explain why this CPU I/O is so weak to have high risk of damaging with so lower level current, because in the real working environment, the ESD or other interference signals(like unstable electrical grid) can cause the IO signal exceed the 5V.
Could you please answer my colleague Kelvin's concern? Thank you!
the measured voltage is most likely derived from the voltage divider of the external pull up and an internal pull down on the GPIO. You should not rely on any internal resistor for voltage divider. It needs to be taken care of external to the device.
Ultimately, the voltage levels at the pin need to conform to the DC electrical characteristics and the Absolute Max Ratings specifications in the datasheet. The IO voltage at any pin should never be higher than the IO supply voltage +0.3V. If it is, you risk damage to the IO

e2e.ti.com/.../gpio-pullup-pulldown-values-on-am335x
the I/O cells of AM335x are dual-voltage, but this is fixed, i.e. they operate either at 1.8V or 3.3V, depending on the VDDSHVx voltage, which powers the I/O cell. This can be see in Table 4-1 from the AM335x Datasheet Rev. J.
all I/O pins of the Am335x belong to a specific power-domain. If a power domain is powered mit a 1.8V regulator, the I/O pins has 1.8V characteristics, i.e. it drives 1.8V. The output voltage cannot be changed by software. So in an existing design you have a problem. One possibility is to define the output as tristate, disable pullup/pulldown and give it an external pull-up to 1.8V. For a low-level you drive the output low, for a high-level you set the pin to tristate. Never drive the output high.

e2e.ti.com/.../6238235

e2e.ti.com/.../1150309

e2e.ti.com/.../2890846

e2e.ti.com/.../1620224

e2e.ti.com/.../1737907
I cannot recommend any value since I don't know any details about the particular schematics. Internal PU/PD values can be calculated from the "Iin with pullup enabled" resp. "Iin with pulldown enabled" parameters in the DC electrical characteristics. Typical values are 18kOhm at 1.8V or 33kOhm at 3.3V, but you will see that min/max currents have a wide range, so this should be taken in consideration when doing calculations.

e2e.ti.com/.../am335x-io-pin-as-input-issue
You have the internal pulldown enabled in pinmux. It is equivalent to approx. 18kOhm, so the 2.4V high level you see is not strange. If you disable the pulldown (it should be OMAP_MUX_MODE7 | AM33XX_PIN_INPUT) the high level should rise to 3.3V.

e2e.ti.com/.../4561201
You can see the reset state of each pin in the "Pin Attributes" table in the datasheet. (Section 6-2 / Table 6-1)

BALL RESET STATE: The state of the terminal at power-on reset:
• DRIVE 0 (OFF): The buffer drives VOL (pulldown or pullup resistor not activated).
• DRIVE 1 (OFF): The buffer drives VOH (pulldown or pullup resistor not activated).
• OFF: High-impedance
• PD: High-impedance with an active pulldown resistor
• PU: High-impedance with an active pullup resistor

e2e.ti.com/.../6052044

I2C
e2e.ti.com/.../5941760
e2e.ti.com/.../1149449
The I2C specification requires pull-up resistors on both lines. If you are thinking about using AM335X internal pullups, their value is too high for I2C to operate properly.
e2e.ti.com/.../164746
If the datasheet numbers still worry you, you could try another approach where the output pin as used as an open-drain with an external pull-up resistor so that VOH is achieved by putting your IO pin in high-Z, and a VOL is achieved by driving a logic low. Then your VOH is determined by the board components.

ePWM
e2e.ti.com/.../2372202
The outputs of one module (i.e. EPWMxA and EPWMxB) will almost always have the same frequency. However, there are some corner cases where you can configure EPWMxA and EPWMxB to have different frequencies. These frequencies, though, will have some limitations (or dependencies) since they both share the same time-base period (TBPRD)

McASP
e2e.ti.com/.../3786338
If the signal transitions too fast at the AM335x input pin, it can turn on the ESD cell which can sink a lot of current. If the signal transitions too slow it can remain in the threshold region for too long causing both P- and N-regions of the CMOS input buffer to shoot through, eventually causing electromigration damage. It is best to adhere to the datasheet requirements.
The transmission line on the PCB signal trace can take some of the edge off of fast rise and fall times. Recall a transmission line can is modeled with connected resistors, inductors, and capacitors which slow the edge rate down. The datasheet for the output buffer of the connecting device might have a rise/fall time that is faster than the Table 7-80 McASP Timing Conditions minimum timing, but the rise/fall time may be within range at the AM335x input pin. This can be measured or simulated with HyperLynx.
If the ESD cell turns on for a signal with rise/fall that is faster than the datasheet requirement, the signal will become distorted as the ESD clamp sinks lots of current.
I will ask what voltage levels is assumed for the rise/fall timings. Give me a couple days.

The minimum rise/fall time is set to a realistic minimum to bound the timing analysis exercise. Maximum rise/fall time (slowest) is the one that usually limits performance. We try to specify a realistic minimum to bound the timing analysis. The timing models we use in timing analysis need a bounded rise/fall time so using 0 (or infinite slope) results in inaccurate and sometimes just wrong timings.

It seems unlikely in real world applications, that the chip would be driven so fast that the fastest input slew rate (smallest rise/fall time) would cause issues.
To avoid the ambiguity of the voltage thresholds assumed for the rise/fall timing, datasheets of newer devices like AM64x specify a min and max input slew rate instead of a time between two voltage thresholds that are not explicitly defined.
I am not sure I understood your reply correctly. Could you clarify which parameter customer needs to follow for AM335x McASP input/output slew rate?
My apologies. For AM335x, the voltage thresholds for the tRise and tFall timings are not specified in the datasheet. The part is old and the thresholds cannot be confirmed.
If the customer wants to be conservative, then they can assume worst case thresholds for min and max tR/tF.
For min tR/tF, assume the 1ns is for the input signal to transition from VIL to VIH (tR) or from VIH to VIL (tF). If the connected device signal rise/fall time is specified from 20% to 80% then the transition from VIL to VIH will be faster.
For max tR/tF, assume the 4ns is for the input signal to transition from 0% to 100% (tR) or from 100% to 0% (tF). If the connected device signal rise/fall time is specified from 20% to 80% then the transition from 0% to 100% will be slower.
If the connected device satisfies these worst case rise/fall times then it will certainly satisfy the actual rise/fall requirements that cannot be precisely defined due to missing voltage threshold information needed to define the rise/fall times.
Again, the rise/fall time must be satisfied at the AM335x device input pin (not at the output pin of the connected device). The board trace may smooth out the edges, slowing down the rise/fall time from the connected device. Additional components like a series resistor may be implemented to further slow the signal edge rate if necessary.

DDR
e2e.ti.com/.../am3352-regarding-the-pull-up-resistor-of-ddr3-reset-signal

MMC1
e2e.ti.com/.../5968754
e2e.ti.com/.../6024763

I2C
e2e.ti.com/.../am6442-rc-delay-for-open-drain-ios-when-pulled-to-1-8v-or-3-3v
e2e.ti.com/.../5902795

Jtag
e2e.ti.com/.../4407030
You are not showing connections to EMU[1:0] pins, so I want to include them in this discussion. The EMU[1:0] pins as well as the signals shown pulled up/down in the snapshot inserted above are inputs to the device. The device has internal pulls on each of these inputs, but the internal pulls are weak. The weak internal pulls may not be strong enough to hold the inputs to a valid logic state when your system is exposed to electrical noise that couples into the PCB board traces. Therefore, you should only rely on the internal pulls when no signal traces are connected to the device package pins. You should use the stronger external pulls to hold the signals to a valid logic state anytime you connect signal traces to the device package pins because the signal traces can act like antennas and pickup noise that over-drives the weak internal pull resistors.
These pulls need to be on the motherboard and located near the processor.
Any signals routed off-board via connector should also have ESD protection circuits. The ESD protection built into the processor pins is only effective for device handling during PCB assembly. They are not able to protect the device from the much higher energy system-level ESD events that may occur once installed in a system. The product designer is expected to provide system level ESD protection on any signal which could potentially be exposed to an ESD event. These ESD protection circuits should be located near the connector.
The TDO pin on the processor doesn't need to be pulled to a valid logic state since it is an output only, but the debugger attached to this signal may need an external pull-up to hold its input in a valid logic state when the processor is not driving the TDO output.
I seem to recall the IEEE 1149 specification says the TDO pin is a high impedance output when not transferring data over the interface. You could research your specific debugger requirements or simply add an external pull-up to be safe.

e2e.ti.com/.../5879997
e2e.ti.com/.../5434783
If they are connecting any signal trace to the JTAG device pins, the EMU[1:0], TCK, TDI, TDO, and TMS signals should have an external pull-up resistor and the TRSTn signal should have an external pull-down resistor. External pulls are required because the internal pulls may not be able hold the signals in a valid logic state when noise is coupled to the JTAG signals. The noise coupling concern can occur when the JTAG signals are routed to a connector and a debugger is not connected and/or driving the signal to a valid logic state.
e2e.ti.com/.../am3358-no-pullups-on-emu0-1
If you have JTAG available, it might be possible to start the board, if it's in Wait-in-Reset mode. That depends on how the EMU pins are sampled at boot. But that will only work with JTAG connected and by communication with the ICEPick tap controller. You might be able to boot the board and do some debugging, but there's no way around a PCB respin.
e2e.ti.com/.../am3358-emu0-1-pullups-during-initial-power-up
e2e.ti.com/.../3228729
e2e.ti.com/.../5829713
e2e.ti.com/.../5874591
The resistors should not be needed as the IO are tuned to 50-ohms output impedance, which should match the PCB. If using for source termination - yes should be placed near source (Processor). If using for other visibility/modification/etc - then could be placed at other locations (example near emulator connector).
e2e.ti.com/.../am5716-pullup-on-tms-and-tclk-signals
The AM5716 contains internal pull resistors to keep them at their inert levels. If track is added, these signals should have external pull resistors added for optimum noise immunity. Therefore, TCK, TDI and TMS should have external pull-up resistors and TRSTn should have an external pull-down resistor when an emulator connection is implemented. This is consistent with the general JTAG guidance provided in SPRU655 and related documents.
e2e.ti.com/.../3486536
Is you concern about the XDS110 not supporting 1.8V based on a board having it connected directly to a device that is operating at 3.3V? If so, that may not be correct.
I'm not familiar with design details of the XDS110 debugger, but most debuggers have an IO supply detect signal which is used to select the IO voltage or simply power an internal level shifter.
I went to the XDS110 link you inserted in your post and found the following comment which seems to indicate the XDS110 can support any IO voltage from 1.8V to 3.6V. So it doesn't appear you would need to insert any level-shifters in the path.
The XDS110 family supports the traditional IEEE1149.1 (JTAG) as well as IEEE1149.7 (cJTAG) and ARM Serial Wire Debug (SWD)/Serial Wire Output (SWO) and operates with interface levels of +1.8V up to +3.6V.
Level-shifters insert delays in each signal path which may require you to reduce your TCK operating frequency.
The IEEE 1149.1 specification requires JTAG output signals to change on the falling edge of TCK and JTAG input signals to be latched on the rising edge of TCK. Therefore, reducing the TCK operating frequency provides additional setup and hold time which allows you to compensate for the additional insertion delay
e2e.ti.com/.../3474707
e2e.ti.com/.../2188694
the AM335x JTAG interface can be used for boundary scan.

Boot
e2e.ti.com/.../1950245
f you search the DC Electrical Characteristics section for the terminal name of interest and do not find it explicitly listed, you should use the data from "All other LVCMOS pins (VDDSHVx = 3.3 V; x = 1 to 6)" if operating the respective VDDSHVx at 3.3 volts, or you use the data from "All other LVCMOS pins (VDDSHVx = 1.8 V; x = 1 to 6)" if operating the respective VDDSHVx at 1.8 volts. In your case the terminal of interest is LCD_DATA and all of the LCD_DATA terminals are powered by VDDSHV6.
1 volt is near the limit for either use case, so you are just getting lucky. You should try to understand why is it not lower and try to resolve the issue.
The VIL max published in the data sheet is a conservative value. The actual switching threshold is most likely near VDD/2 which could be considerably higher than 1 volt if you are operating the IO supply at 3.3 volts.

e2e.ti.com/.../am3358-sysboot-pins-connection
There are 16 pins that are used to select booting sequence of AM3358 (R1~R4, T1~T4, U1~U4, V2~V5). I am using 100K resistors to pull the pins to high or low. Since the booting sequence is fixed in my design, can I just use straight connection to 3.3V or GND instead of using resistors to configure booting sequence?
This is absolutely forbidden. You can permanently damage the device if you do this.
My thought was: these booting configuration pins have high input impedance, so I would like to use a straight connection to VCC or GND to simply the hardware design. Could you explain more why a straight connection instead of resistor will damage the device?
Because these pins can be inadvertently configured as outputs by software. Besides, it's bad practice to tie digital inputs directly to a voltage source, without a current limiting resistor.
e2e.ti.com/.../5575812

e2e.ti.com/.../am335x-bootstrapping-resistor-values
The external pull resistors required on the LCD_DATA[15:0] signals are used to select the proper boot sequence of the AM335x device and these resistors should not effect signal quality when driving the LCD.

The value of these pull resistors should be selected based on the worst case input leakage of all inputs connect to these signals and the VIH min and VIL max voltage levels defined in the AM335x data sheet.

For example, the maximum pull-up value required to pull these inputs above the VIH min voltage is 63k ohms assuming 3.3 volt operation with a min VDD supply of 3.135 volts and no other connection to these terminals. This resistor value may need to be even smaller if you have other devices connected that have leakage to VSS. The same is true for the maximum pull-down value. With the same assumptions, the maximum pull-up value required to pull these inputs above the VIL max voltage is 44k ohms.

I actually found the problem. Turns out that I need to pull pin 17 on the SN75LVDS83 to GND as opposed to VCC to clock data in on the trailing edge of the input pixel clock. Apparently my LCD data traces are just long enough to run into some marginal timing clk / data issues....
The noise I was seeing actually turned out to be mostly due to scope probe ground lead inductance

RGMII
e2e.ti.com/.../1437746
These resistors are not *required* from the TI-side, but it can be a good idea to have zero-Ohm options present on the board in case excessive reflections are seen. If implemented, they should be placed close to the TX pins to be most effective.
I cannot comment on the Marvell requirements...the customer really should have access to their docs if they plan on implementing their device...
e2e.ti.com/.../am437x-rgmii-series-resistors
e2e.ti.com/.../4690676
You mention SGMII, but I believe you mean RGMII. Series resistors are used to match the output impedance of the driver with the impedance of the PCB trace (in effort to improve signal integrity). Series resistors are typically not needed on TDA4VE outputs because IO output impedances are typically set to 50-ohms (matching most PCB trace impedances).
For the TDA4VE EVM - the RGMII traces are fairly long, and so signal integrity is a concern. Series resistors are placed near the Ethernet PHY to better match its outputs with the PCB traces. These resistors are less critical on the SK-AM68 as the traces are shorter and thus signal integrity is not as much a concern.
e2e.ti.com/.../3847978
The AM335x IO select their operating voltage based on the voltage applied to their respective power rail when reset is released. Therefore, you must make sure the IO voltage does not change after reset has been released.
e2e.ti.com/.../3816623
The MDIO Alive bit indicates which phy address are acknowledging the MDIO polling operations.
The MDIO block will pole all Phy addresses 0 thru 31 and any Phy responding to the status request with an ACK will be reported in the MDIO Alive register. The status of the link bit will be reported in the link register.
Since a MDIO Phy can be programmed (normally via pullups/downs) to a particular phy address The MDIO module can identify which Phys are present.
IEEE states that the Phy attached via a mechanical MII interface connector should be Phy address 0x0.
There were some Phy manufacturers that miss-read the standard, thinking Phy address 0 was a broadcast register, that is writes to all Phys. But that is not within the standard and only exist is very few Phys. Phy address 0x0 was reserved for the mechanical connector.
The Phy address as determined via MDIO poling does not specify which xMII it s attached. The board developer specifies which Phy is attached, and uses the Phy specific methods to set the Phy address.
Care must be takes as some Phys use the MII pins to configure the Phy address, and if the signal is being driven and a hard reset occurs, could miss-program the Phy address.
e2e.ti.com/.../2936873
Each PHY must have a different address. Normally this is done by pin strapping on the PHY.
e2e.ti.com/.../2047714
The state of some SYSBOOT inputs may not be relevant for a specific boot mode and in this case they can be either a logic high or logic low. However, you should never leave any inputs floating. Since the SYSBOOT inputs do not have internal pull resistors turned on by default, you must use external resistors to pull theses inputs to valid logic levels.
e2e.ti.com/.../dra80m-what-is-rgmii-series-resistor-value-and-absolute-maximum-ratings
The value of the series termination resistor is dependent on the specific design. The PCB's target impedance could drive different resistor values. It is possible no resistor is required. Recommend using the IBIS model customer's PCB simulation to determine if resistor is required and if so, the specific resistor value.
e2e.ti.com/.../am3358-internal-i-o-supplies
I am using TPS65910 for the AM3358. All the supplies for the IO domain (VDDSHVx) are set to 3.3V operation. Take as an example the Ethernet RGMII2 that uses the VDDSHV5. Am I right to assume that is ok to connect my Ethernet PHY directly to a 3.3V supply that is generated from an LDO on my card and not using the VDDSHV5 as long asd the voltage levels is the same? Any recommendation for the layout in this case?
Yes, you can use a separate power source for the PHY, as long as the interface voltage levels are the same. I don't understand what recommendations you need for layout - this is board dependent. Try to keep the Ethernet interface lines as short as possible.
A further clarification has come in from the AM335X team:
Keeping the Ethernet signals short may not be a good answer for all Ethernet PHYs. Customers need to perform timing analysis using input setup/hold requirements and output delays of each device (AM3xxx and Ethernet PHY) along with any PCB delays to determine if all timing parameters are being satisfied.
There is also a requirement of keeping the two supplies at the same voltage while they ramp-up and ramp-down so that one device does not source a input voltage greater than the respective VDD + 0.3 volts.
e2e.ti.com/.../5755025

Oscillator
e2e.ti.com/.../am3358-ep-overdriving-oscillator-input
I know that 1.8V LVCMOS oscillators are hard to find, so the solution can be using an 3.3V oscillator and a 1.8V buffer between it and the OSC0 input.

SPI
e2e.ti.com/.../am5728-mcspi-pullup-resistors
What you ask is design specific. There is no general answer to your questions. You need to check your signal waveforms to see whether external pullups are needed.
UART0
e2e.ti.com/.../4121850
I found this schematic for the BBB revC3. github.com/.../BBB_SCH.pdf
Page 4/11 shows 100K resistor (R165) connecting B_UART0_RX to ground. I have temporarily added a 100K resistor across pin-1 to pin-4 of the 6-pin header. I have only tested for 24 hours but I am no longer receiving unwanted characters on UART0 while nothing is plugged on to the 6-pin header.
e2e.ti.com/.../am5728-uart0-garbage-characters
So you getting this out of UART3? With no code running?
Can you try adding a pull-up resistor to your logic-level UART output signal of the device?
Sometimes floating pins can cause random data to be seen by an external receiver, especially when no user code is running yet (that would take care of pinmux etc. initialization). Temporarily adding a pull-up resistor would help making sure that this is not the case here.

Regards,

Sreenivasa

Hi Board designers,

Inputs related to IO functionality and failure mechanism - When GPIO in VDDSHVn gets damage by high voltage etc, Does it affect GPIO in VDDSHV_MCU and cause any damage?

(5) AM2432: Is it possible to prevent propagation of IO failure from MAIN domain to safety MCU domain? - Arm-based microcontrollers - INTERNAL forum - Arm-based microcontrollers - INTERNAL - TI E2E support forums

From datasheet, it is possible to supply different voltage to VDDSHVn and VDDSHV_MCU.
I should tell what Customer wants to do. They want to use MCU domain as safety purpose
There is the mechanism to isolate MCU domain and MAIN domain logically in AM243x. But customer wants to know physical isolation as well as logic isolation. They want to know if it is possible to prevent physical failure propagation from one domain to another domain. This is important for safety purpose.

The answer to the query is use case dependent (type and severity of failure). Refer below Device Expert inputs:
The entire device shares a common VSS, but the IO power rails are completely isolated from each other. Each IO cell has a portion of its circuits which are powered from its respective IO power rail and a portion of its circuits which are powered from the device’s common VDD power rail. Each IO cell contains level-shifter circuits used to bridge the potential difference between the common device core power rail and the respective IO power rail. The level-shifter circuits convert all out-bound signals sourced from core powered circuits to the IO operating potential, and converts all in-bound signals sourced from IO powered circuits to the core operating potential.

Can you please add your thoughts on the below customer query:
Customer wants to know if VDDSHVn and VDDSHV_MCU is physically isolated and the failure occurred in one domain does not propagate to another domain.
For example, they want to know if bidirectional diode is implemented between two power domain and it does not propagate physical failure from one domain to another domain.

Customer seems to be interested in what may happen if there is an failure of the IO. However, it is not clear what they are expecting to happen that causes the IO failure. Are they assuming the IO failure is the result of a device that simply stops working as expected or is the IO failure the result of an external influence like Electrical Over-Stress (EOS). The only reason an IO should fail is when their system implementation allows an Electrical Over-Stress (EOS) condition to be introduced on the signal and that event damages the IO of the AM243x or attached device.

The answer to the question depends on the failure mechanism and the level of damage created when there is an Electrical Over-Stress (EOS) condition. There is a small possibility of damaging an IO cell bad enough that it impacts the common core power domain, which could impact the entire device, but the typical EOS condition doesn’t damage the IO cell bad enough to propagate to any other power domains.

I tried to address the specific example they provided by saying “the IO power rails are completely isolated from each other”.

Reference

/cfs-file/__key/communityserver-discussions-components-files/791/SPRACP2.pdf

 AM2432: Communication between MAIN domain and MCU domain when FFI is configured 

Regards,

Sreenivasa