This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: AM625
Other Parts Discussed in Thread: AM623, AM4376, AM5716, AM3358, SN75LVDS83, SK-AM68, TPS65910
Tool/software:
Hi TI Experts,
Is there any application note with information about how to connect IOs or Peripherals - Used or Unused
Details on the connections to be done when used.
When not used, should these IOs or Peripherals be left unconnected or connected to an pull-up or pull-down resistor.
Hi Board designers,
Handling of the Used IOs or Peripherals and Unused IOs or Peripherals depends on the family of processors.
The Following documents could be references
Device specific data sheet
Device specific Errata
Hardware Design Guide for family of devices
Schematic Design and Review Checklist for family of devices
These documents are available on the device specific product folder on TI.com. The product folder has many ore documents and tools that makes designing customer board simpler.
if you have any questions or not able to find the right collateral, reach out to TI support over E2E.
The assigned TI expert can point you to the required collaterals and also provide additional guidance.
Additional references
Regards,
Sreenivasa
Additional inputs for Decoupling caps on CAP_VDDSx
Customer's asking what will happen if the decoupling caps on the CAP* nets below are not installed correctly? Will the device's behavior be well defined in this case (i.e. fail to boot etc) or would it be more sporadic based on operating mode? They are preparing manufacturing test definition and wondering about scenarios such as
DNP incorrectly.
One or more of the caps are damaged due to handling and result in:
open
short
Is there any defined behavior for wrong values of the capacitors that can be captured in testing?
Refer below FAQ
(+) AM623: Short circuits on CAP_VDDSx pins - Processors forum - Processors - TI E2E support forums
AM623: Short circuits on CAP_VDDSx pins
I have just found this similar question:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1254617/am623-decoupling-caps-on-cap_vddsx
Is it possible to know if the internal LDOs have over-current protection or a max Iout prior to damage?
The LDOs were not designed to accommodate a short since the only external connectivity is the capacitor. You should assume the associated LDOs were compromised even if they are working after removing the shorts.
Regards,
Sreenivasa
Additional inputs for handling RSVD pins
If these signals are short-circuited, what will happen? I am thinking of cases such as a short circuit on each terminal in terms of functional safety. If there is no error in the functional test, there is no issue with the shorted RSVD pins or we don't have any shorts?
Most of the reserved pins are analog test pins which are not driven during normal operation. These pins should always be in normal operation mode in a customer’s system since we do not allow customers to access the test functions associated with the analog test pins. Therefore, we do not anticipate an issue if they were accidently shorted to an adjacent ball.
This comment does not give customers permission to connect any signal traces to these pins.
There could be an issue if these pins were shorted to a power supply of higher potential. For example, a 1.8V power rail may be connected to a 3.3V power source via the pin’s ESD clamp circuit if one of the pins were shorted to 3.3V. In this case, the internal clamp diode would be forward biased and the higher potential would flow through the clamp diode and raise the potential applied to the 1.8v power rail. This could potentially create multiple EOS issues for the device.
Regards,
Sreenivasa
Additional inputs on selecting pulls (pullup or pulldown) for LVCMOS IOS
Customer is using 100K pulls. Given the below leakage current, is this a concern. Should customer be reducing the pull value?
IIN Input Leakage Current.
VI = 3.3 V or VI = 0.0 V ±10 μA
Which IO cell? Pull-up or pull-down?
These are SPI interfaces, emulated I2C interfaces ( not sure if they used as I2C since this goes to a connector) and IOs switching FET to indicate fault or for LEDs
LVCMOS IOs. Customer has used pullup as well as pulldown for different IOs. Not sure if I answered your query.
The customer should be validating these types of things based on their custom system design.
They need to select a resistor that is able to hold the signal above the steady-state high (VIHSS) or below the steady-state low (VILSS) based on the signals worst-case combination of leakage, which will be the sum of the max leakage of all attached devices.
For example, let’s assume they only connect our device to a single UART device that has a max leakage of 5uA when operating at 1.8V. The worst-case leakage would be 10uA + 5uA = 15uA. VIHSS for the LVCMOS IO cell operating at 1.8V is 0.85 x VDD = 1.53V. A pull-up resistor value would need to be at less than 18k ohms to hold the voltage above 1.53V for a worst-case leakage of 15uA. I would suggest they use a value that is less than 18K ohm for this example.
In this example, one end of the resistor is connected to VDD and the other to the signal. The voltage across the resistor must be less than 1.8V – 1.53V = 0.27V to maintain the proper steady-state VIHSS level. If the signal had a total of 15uA of leakage to ground the max voltage drop allowed across the resistor is 0.27V when the 15uA of current is flowing from VDD through the resistor to the ground. Therefore, the resistor would need to be less than 0.27V/15uA = 18k ohms.
Which IO cell? Pull-up or pull-down?
You asked me about the IO cell. Not sure on the reason. Any thoughts please.
I tried to find myself, looked at all the IO cell specs and all of them seem to specify ±10 μA
Because the VIHSS and VILSS values are different for the different IO types and if an internal pull is turned on the internal pull values are different. The leakage due to an internal pull being turned on is not included in the Input Leakage Current parameter values.
Are the VIHSS and VILSS value changes associated with the IO type and TI specific or based on JEDEC standards?
JEDEC does not define VIHSS or VILSS parameters.
The voltage limits defined by these parameters are specific to the IO design and operating voltage. The signal voltage needs applied to our input buffers must be above VIHSS or below VILSS when the signal is held in a steady-state condition. These parameters are needed to limit the shoot-through current that flows from VDD through the input buffer to VSS when the signal voltage is not pulled all the way to VDD or VSS. Staying above VIHSS or below VILSS will minimize the shoot-through current when the signal is not toggling. Too much exposure to shoot-through current has a chance of damaging the input buffer. The shoot-through current peaks to its maximum when the signal voltage is about VDD/2, and drops off very quickly as the signal voltage approaches either VDD or VSS. This is why we must limit the input slew rate, to minimize the time the signal voltage is in the mid-supply region. The shoot-though current drops low enough that it will not cause any long-term reliability issues when the signal voltage is above VIHSS or below VILSS. In some cases, the VIHSS and VILSS limits are the same as the JEDEC VIH and VIL limits.
The standard JEDEC VIH and VIL limits define the DC limits associated with valid logic states. The TI VIHSS and VILSS limits define steady-state DC limits required to ensure long-term device reliability.
Data sheet reference
Electrical Characteristics
IIN Input Leakage Current for different IO types (LVCMOS, SDIO, Open drain and other IO types as applicable)
Regards,
Sreenivasa
Additional inputs on pulls used on the SK or EVM
TI recommendations are being provided as good starting point for the custom board designer, but the custom board designer must validate all TI recommendations are appropriate for their specific board and end equipment implementation
Regards,
Sreenivasa
Inputs related to series terminations and parallel terminations
GPIO
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.
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/.../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
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.
