Hi Board Designers,
VDD_MPU_MON Connections
This pin was meant to provide feedback to the PMIC so the point of regulation is closer to the processor. In this case it is returned from on-die connections.
The feedback was never expected to compensate for high frequency power demands sourced by local decoupling capacitors. This pin was provided as a way to minimize dc voltage drop across power traces of the PCB and device package.
This may become more important if decide to support higher speed grades in the future.
We recommend connecting this pin to the VDD_MPU power source if it is not going to used as a Kelvin connection to the PMIC or leave it open.
This terminal provides a dedicated Kelvin connection to the VDD_MPU power rail on the AM335x device. When it is not used to provide feedback to a voltage regulator circuit it can be used as another VDD_MPU power terminal.
VDD_MPU_MON is not meant to carry current; it is simply a Kelvin connection to VDD_MPU to monitor the voltage inside of the SoC. Because of inductance introduced in signal paths, we find most PMIC applications are better suited without it (leave it floating).
This pin is used if you want to provide feedback to the PMIC directly from the AM335X VDD_MPU internal plane. This would negate voltage drops over the external VDD_MPU rail. If a good solid VDD_MPU power plane is designed on the PCB this connection is usually not necessary and VDD_MPU_MON can be directly tied to VDD_MPU.
Before using the AM335x VDD_MON terminal, you need to confirm the power supply being used allows a remote sense that originates at the load. Many power sources are only stable when the feedback path is located near the power supply output. These power supplies may not provide a stable ouptut when using a remote sense like the one provided by the AM335x VDD_MON terminal.
What is you opinion on using the VDD_MPU_MON output from the am335x to the TPS65217C pmic feedback pin to help compensate? Will the PMIC be able to remain stable?
The VDD_MPU_MON terminal was added as a way to provide a remote feedback to the power source. However, we found the PMIC output was not stable when VDD_MPU_MON was connected to the PMIC feedback input. This instability occurs because the PMICs were designed with an expectation that the feedback input would be connected directly to their output capacitor.
What is the intended usage of VDD_MPU_MON? Is this intended to be a galvanic sense pin to feed back to the PMIC?
The answer to the question is, yes.
This terminal is an isolated connected to the VDD_MPU domain on the silicon. The plan is to connect this terminal to the PMIC feedback input so any voltage drop on the VDD_MPU signal path can be compensated by the power supply.
AM335x: VDD_MPU_MON left floating
Not connecting the VDD_MPU_MON terminal to a power source is equivalent to not connecting one of the VDD_MPU power terminals.
this signal does not have a low enough impedance inside the AM335x device to be useful power source. Therefore, system performance is not compromised by not connecting the VDD_MPU_MON terminal to the VDD_MPU power source.
We recommend this terminal be connected as shown in the AM335x data sheet.
AM3358: impedance value between VCC_CORE and GND
You need to be careful using a multimeter to measure impedance of a semiconductor pin. Some multimeters may source a potential that is greater than the recommended operating condition of the pin being measured. If so, there is a chance the measurement could create an Electrical Over Stress (EOS) condition for the pin and damage the device.
There is another concern. If the multimeter sources enough current to power a pin, this is likely a violation of the device power sequence requirements.
Regards,
Sreenivasa
Hi Board Designers,
FYI, related to USB interface:
PROCESSOR-SDK-RTOS-AM335X Software development kit (SDK) | TI.com
(+) AM3352: AM3352 USB Eye Diagram Pattern - Processors forum - Processors - TI E2E support forums
AM3352 USB Eye Diagram Pattern
For device mode, USB_ID pin needs to be left floating. The above schematic capture does not reflect this. Please confirm USB_ID state in your system.
Once this is done and assuming you are using Linux, the 'modprobe g_zero' commands needs to be used. Are you able to see the below after entering this command?
in our reference design, there's a 120uF for USB application. can this 120uF electrolytic capacitor be replaced by ceramic capacitor？
and can this 120uF be divided into several smaller capacitors?
Generally, it should be ok, but please pay attention to the following differences:
1. The value of ceramic capacitor can drop when the applied voltage is higher. Please choose ceramic capacitors with higher voltage rating or leave more margin in capacitance selection.
2. Ceramic caps usually have relatively smaller ESR. When several smaller caps in parallel the ESR can be even smaller. The dumping performance can be influences so please check whether it's necessary to add small resistors in the loop.
3. Thermal performance can be different, please check the application condition and datasheets.
4. The price can be different.
ou need to add the 120uF cap, you can refer to the below document.
M335x USB ID pin is controlled like follows.
USBn_ID has voltage applied by 120kΩ Pull Up. Does this circuit damage AM335x?
AM335x didn't change to USB Host even they pulled off the 120kΩ Pull Up.
Yes, this circuit will certainly damage the AM335x device. Please see bullet #1 in the schematic review checklist.
processors.wiki.ti.com/.../AM335x_Schematic_Checklist
another question is if we don't use the FAULT function, can this pin left float? I see it's an OD structure.
Yes, I think you can leave it float if you are not using it, since it's active-low open-drain output.
Regards,
Sreenivasa
Hi Board Designers,
https://www.ti.com/lit/ds/symlink/am3358.pdf
Reference:
7444.TMDSSK3358_3H0009_REV1_3A_SCH.pdf
5.9 External Capacitors
To improve module performance, decoupling capacitors are required to suppress the switching noise generated by high frequency and to stabilize the supply voltage. A decoupling capacitor is most effective when it is close to the device, because this minimizes the inductance of the circuit board wiring and interconnects.
Reference:
2335.tmdxice3359_sch_3h0013_v2_1a.pdf
Schematic Reference
0763.TMDSSK3358_3H0009_REV1_3A_SCH.pdf
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to DDR3 interface capacitors for processor and memory device
https://www.ti.com/lit/ds/symlink/am3358.pdf
7.7.2.3 DDR3 and DDR3L Routing Guidelines including capacitors
This section provides the timing specification for the DDR3 interface as a PCB design and manufacturing specification. The design rules constrain PCB trace length, PCB trace skew, signal integrity, cross-talk, and signal timing. These rules, when followed, result in a reliable DDR3 memory system without the need for a complex timing closure process. For more information regarding the guidelines for using this DDR3 specification, see Understanding TI's PCB Routing Rule-Based DDR Timing Specification. This application report provides generic guidelines and approach. All the specifications provided in the data manual take precedence over the generic guidelines and must be adhered to for a reliable DDR3 interface operation
Note section of data sheet DDR3 Signal Termination when VTT terminations are not used
Schematics reference
Schematic reference:
5700.TMDSSK3358_3H0009_REV1_3A_SCH.pdf
Is DDR CLK_P/N termination required?
With proper trace impedance, we have never required that the differential clock be terminated for single device DDR3 designs with AM335x. Don’t forget, AM335x max DDR freq is 400MHz (vs 800MHz for AM64x), so I believe we started recommending this for AM64x and beyond due to the increased frequencies. I found some discussion of this here:
Let me try to explain why you may not need to terminate the differential clock as you suggest.
There is a very good chance you may not need to terminate the clock at the DDR3 end of the transmission line if you design your PCB clock traces to the recommended characteristic impedance defined in Table 5-58 of the AM335x Data Sheet.
The following description only applies in the case where you use a single DD3 device and all signal traces are connected point-to-point.
When a voltage transition in launched on the transmission line, the voltage of the signal trace at the source will suddenly transition to a voltage defined by the voltage divider equation [Vout = Vin * Z2 / (Z1+Z2)] where Z2 is the characteristic impedance of the transmission line, Z1 is the impedance of the AM335x output buffer, and Vin is VDDS_DDR. The voltage at the source end of the transmission line will remain at this voltage until the voltage transition propagates to the DDR3 high impedance input which causes the voltage transition to be reflected and returned to the source. Once the reflection returns to the source the voltage at the source will complete the transition to VDDS_DDR. If you monitor the voltage at source end of the transmission line with a scope, it appears to step up to a mid-supply voltage level for a short period of time before it continues to transition to VDDS_DDR. This short period of time where the voltage is mid-supply will be two times the signal trace propagation time.
This mid-supply voltage step can be seen anywhere along the transmission line, but the period of time where the voltage is mid-supply gets shorter as you approach the DDR3 end of the transmission line and completely goes away at he DDR3 end of the transmission line. If you monitor the voltage at the DDR3 end of the transmission line, you would not see this mid-supply voltage step since this is were the voltage transition encounters the impedance discontinuity that causes the refection. Therefore, the DDR3 device sees a clean low-to-high or high-to-low voltage transition.
If the characteristic impedance of the PCB signal trace matches the impedance of the AM335x output buffer the returned reflection does not see an impedance discontinuity so there is no additional reflections to cause signal integrity issues. When these impedances are matched the mid-supply voltage step should be [VDDS_DDR / 2].
This behaviour is the same for single ended or differential signals as long as the impedance of the PCB signal trace matches the impedance of the AM335x output buffer and the only other impedance discontinuity is the high-impedance input of the DDR3 device.
We still recommend system performance should verified by performing signal integrity analysis using specific PCB design details before implementing this topology.
From the AM335X Datasheet Rev. G, section 7.7.2.3.3.9:
"Figure 7-48 provides an example DDR3 schematic with a single 16-bit DDR3 memory device that does not have VTT termination on the address and control signals. A typical DDR3 point-to-point topology may provide acceptable signal integrity without VTT termination. System performance should be verified by performing signal integrity analysis using specific PCB design details before implementing this topology."
As an alternative you could directly copy the Beaglebone Black DDR3 layout (you should keep the same PCB stackup too). Beaglebone Black design files can be found here: http://elinux.org/Beagleboard:BeagleBoneBlack#Hardware_Files
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to crystal ground connection
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to connection of signals for RTC functionality
Schematic Checklist (reference in the above FAQ)
AM335x Schematic Checklist
www.ti.com/.../sprabn2
Previous revision that includes RTC information
2.14 RTC
Table 2 describes what to do with each pin related to RTC functionality. Three use case scenarios are
provided:
• RTC-only mode: If you will be using the low power RTC-only mode. This use case allows low power
operation of the AM335x by allowing only the RTC power supply to be ON while all the remaining
supplies are OFF.
• RTC timer functionality but no RTC-only mode: If you will be using the RTC feature but do not need
RTC-only mode. This use case allows you to use the Real Time clocking features (keeping time), but
you do not need to support the low power RTC-only mode.
www.ti.com References
SPRABN2–March 2019 9
Submit Documentation Feedback
Copyright © 2019, Texas Instruments Incorporated
AM335x schematic checklist
• RTC feature disabled: If you will never use the RTC features. In this use case, the RTC functions are
fully disabled.
sprabn2.pdf
2.14 RTC
Table 2 describes what to do with each pin related to RTC functionality. Three use case scenarios are provided:
• RTC-only mode: If you will be using the low power RTC-only mode. This use case allows low power operation of the AM335x by allowing only the RTC power supply to be ON while all the remaining supplies are OFF.
• RTC timer functionality but no RTC-only mode: If you will be using the RTC feature but do not need RTC-only mode. This use case allows you to use the Real Time clocking features (keeping time), but you do not need to support the low power RTC-only mode.
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to cold and warm reset
https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
8.1.7 Reset Management
8.1.7.1 Overview
The PRCM manages the resets to all power domains inside device and generation of a single reset output
signal through device pin, WARMRSTn, for external use. The PRCM has no knowledge of or control over
resets generated locally within a module, e.g., via the OCP configuration register bit
IPName_SYSCONFIG.SoftReset.
All PRM reset outputs are asynchronously asserted. These outputs are active-low except for the PLL
resets. Deassertion is synchronous to the clock which runs a counter used to stall, or delay, reset deassertion upon source deactivation. This clock will be CLK_M_OSC used by all the reset managers. All
modules receiving a PRCM generated reset are expected to treat the reset as asynchronous and
implement local re-synchronization upon de-activation as needed.
One or more Reset Managers are required per power domain. Independent management of multiple reset
domains is required to meet the reset sequencing requirements of all modules in the power domain
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to current measurement provision
Schematic Checklist (reference in the above FAQ)
AM335x Schematic Checklist
www.ti.com/.../sprabn2
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to PRU GPIO
AM3358: What is the maximum achievable speed of dedicated PRU GPIO toggling
I have not observed any limitations in hardware testing. Based on the datasheet, your code should be fine as long as the pulse width for both input and output signals is at least 10ns (2 PRU clock cycles). Refer to the datasheet for more details.
Inputs related to enabling pulls for processor IOs
In case there is a discrepancy between the TRM and processor specific data sheet for the default pull configuration, the recommendation is to follow the data sheet:
(12) PULLUP OR PULLDOWN TYPE: Denotes the presence of an internal pullup or pulldown resistor. Pullup and pulldown resistors can be enabled or disabled via software
9.3.1.50 conf__ Register (offset = 800h–A34h)
Data sheet pin attributes
IOs that are driven low or high without enabling the internal pulls
IO that have pulldown enabled after reset
TRM pad control registers
(+) AM335x pad register offset info - Processors forum - Processors - TI E2E support forums
Regards,
Sreenivasa
Hi Board Designers,
Inputs related to Slew Control for IOs
The Pin multiplexing details for GPIO1[8] is given below.
Bit 6 : SLEWCTRL : Fast – 0
Bit 5: RXACTIVE : Receiver Enabled : 1 (Since GPIO1[8] shall be used an Input pin)
Bit 4: PULLTYPESEL : Pullup selected : 1
Bit 3: PULLUDEN : Pullup/pulldown enabled – 0
Bits 2:0 : MUXMODE : 7
Therefore the pin multiplexing code for GPIO1[8] is:
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_UART_CTSN(0)) = (0x20 | 0x10| 0x7)
These are the basic steps to toggle the GPIO line
Pinmux:-
Do pinmux configurations accordingly
GPIO:- Set gpio3 pin to high
Set GPIO value:
gpio_reg_val = 0x00000008; /* for GPIO3 */
writel(gpio_reg_val, GPIO0_BASE + 0x194);
Set GPIO direction:
gpio_reg_val = readl(GPIO0_BASE + 0x134);
gpio_reg_val &= ~(0x00000008);
writel(gpio_reg_val, GPIO0_BASE + 0x134);
Note: Make sure that same pinmux registers are not configured for different purpose
(+) AM335X and GPIO1_20/GPIO3_18 - Processors forum - Processors - TI E2E support forums
What do you mean by address? If you need the address of the pinmux register for the pin you should check the AM335X TRM Rev. L section 9.3.1. Registers named conf_xxxxxxx are the pinmux registers. Pins are named after the pin function in mode 0.
Thus GPIO3_18 is on pin MCASP0_ACLKR (pinmux register conf_mcasp0_aclkr), resp. GPIO1_20 is on pin GPMC_A4 (pinmux register conf_gpmc_a4).
(+) GPIO INPUT FLOATING DEFAULT VALUE - Processors forum - Processors - TI E2E support forums
The slew rate control changes the output buffer drive strength during the rise/fall transitions. I suspect the slew rate is changing at the AM335x terminal or you would not see a difference in SPI1 operation. You may need to measure the slew rate with a high speed oscilloscope and high speed FET probe as close as possible to the AM335x terminal to see the difference. If you make this measurement at the far end on the PCB signal trace using low bandwidth equipment, the high frequency portion of the signal transition will be filtered and may not be possible to see the difference.
I think your problem may be related to a signal integrity issue on the AM335x end of the SPI clock.
The SPI clock is driven out of the SPI1_SCLK terminal to the external device and is also looped back into the AM335x device via the internal IO buffer. Therefore, any signal integrity issue on the SPI1_SCLK terminal end of the PCB signal trace can corrupt the clock signal.
Using the SPI1_SCLK terminal as an input and output simultaneously creates a signal integrity issue at the SPI1_SCLK terminal. The source impedance of the output buffer and transmission line impedance of the circuit board etch creates a voltage divider at the SPI1_SCLK terminal during rising and falling edges of the SPI clock. The voltage at the SPI1_SCLK terminal will change by [VDD * (ZL/(ZL + RS))] when the output buffer toggles and will remain at that voltage until it propagates to the load and the reflection returns. During this time the amplitude of the SPI1_SCLK terminal is close to the switching threshold of the input buffer. Noise may cause the input buffer to generate glitches or invalid transitions of the SPI clock. This will cause problems for the internal SPI logic.
The figure below is provided to help visualize the circuit topology that creates a voltage divider and resultant voltage waveform.
This problem can be resolved by placing a series termination resistor between the SPI1_SCLK terminal and the transmission line. This increases the amplitude of the SPI1_SCLK terminal voltage divider step above the switching threshold so noise will not generate any glitches. This resistor should always be placed as close as possible to the SPI1_SCLK terminal that is sourcing the SPI clock. The value recommended for this resistor is between 22 and 50 ohms. As the resistor value increases the amplitude of the voltage divider step will increase. However the maximum SPI clock speed will decrease. The actual value may need to be determined after the circuit board is fabricated.
Do you have a series termination resistor installed on the AM335x end of the SPI clock?
You right.. We added a resistor between the SPI1_SCLK terminal and the transmission line. It now works.
(+) AM3352: Slow Slew Rate - Processors forum - Processors - TI E2E support forums
1. No, it's available, however the AM335x datasheet has the following statement: 'The timing parameter values specified in this data manual assume the SLEWCTRL bit in each pad control register is configured for fast mode (0b).' This statement applies to all peripherals.
2. No, it will not be ignored, but you will not see any significant difference, as explained in the thread you refer.
(+) AM335x Slow Slew Rate - Processors forum - Processors - TI E2E support forums
Slew rate control is a function implemented in the IO cell of the device and does not have any relationship to specific peripherals. So slew rate control is applied on a per terminal basis via the respective conf_<module>_<pin>_slewctrl bit, where '<module>_<pin>' is the terminal name.
We also determined the IO cells used in AM335x were not providing any significant change in slew rate. Therefore, there wasn't any value in characterizing the device while operating in slow mode.
We do not recommend using slow mode and there is no data for slow mode because of the reasons mentioned above.
I have seen other customers add filters which I assume were inserted to reduce radiated emission.
The LCD should be one of the easier peripherals to filter since all signals are propagating from AM335x to the display. If you use the same filter design on each signal, the insertion delay through the filter should be very similar which allows all signals to retain their timing relationship. However, you may cause signal integrity issues if you slow down the edges too much relative to the fastest signal toggle rate required by the LCD interface.
This is a system level issue which has multiple dependencies that should be considered to determine the best solution for your product.
(+) AM3352: I/O Slew Rates - Processors forum - Processors - TI E2E support forums
The answers to their questions have been answered in the post you referenced.
Does TI have published specifications for the output slew rate of the TX and RX outputs of the UARTs on the AM3352?
We do not publish the output slew, only the max loading (Timing Conditions).
I'm referring https://e2e.ti.com/support/processors/f/791/p/233997/1121323#1121323.
1) Does this mean that the SLOW setting is not available on all pins?
2) If I set SLOW slew rate for it then the setting is ignored? (The setting is forced to FAST?)
1. No, it's available, however the AM335x datasheet has the following statement: 'The timing parameter values specified in this data manual assume the SLEWCTRL bit in each pad control register is configured for fast mode (0b).' This statement applies to all peripherals.
2. No, it will not be ignored, but you will not see any significant difference, as explained in the thread you refer.
If you search the AM335x Data Sheet (SPRS717) for the word "SLEWCTRL", you would find the following statement in the Peripheral Information and Timings section.
The timing parameter values specified in this data manual assume the SLEWCTRL bit in each pad control register is configured for fast mode (0b).
All AM335x Data Sheet timing parameters are based on SLEWCTRL being configured in fast mode. Therefore, slow mode is not support on any of the peripheral interfaces.
The SPIx_SCLK is internally looped back at the pin (as shown in the image peaves posted in the original thread) and used by AM335x to sample the RX data. Any signal integrity issue on the SPIx_SCLK pin will impact the input clock, which is why a series termination resistor is needed.
The SLEWCTRL bits affect the slewrate of the signal. Please note that we only characterized fast mode. While your customer's problem seems to be solved by the SLEWCTRL bits, they could be on the edge and changing SLEWCTRL to slow mode may not be a robust solution across PTV Process - Temperature - Voltage.
(+) GPIO INPUT FLOATING DEFAULT VALUE - Processors forum - Processors - TI E2E support forums
(+) AM335x and DDR3 termination - Processors forum - Processors - TI E2E support forums
All peripheral timing closure was done based on the I/O configured for fast slew. Slow mode is not supported on any peripheral interface and that is why we do not publish timing information for operating in slow mode.
I do not have access to ROM code, so cannot answer your other question. I will forward this post to someone that may be able to answer this question.
(+) AM335x LCD_DATA slew rate and EMI - Processors forum - Processors - TI E2E support forums
If you search the AM335x Data Sheet (SPRS717) for the word "SLEWCTRL", you would find the following statement in the Peripheral Information and Timings section.
The timing parameter values specified in this data manual assume the SLEWCTRL bit in each pad control register is configured for fast mode (0b).
All AM335x Data Sheet timing parameters are based on SLEWCTRL being configured in fast mode. Therefore, slow mode is not support on any of the peripheral interfaces.
The setup, hold, and output delay timing requirements for each peripheral signal is defined before the processor design is completed. The design team will modify the internal circuit delays in the processor to make sure the timing parameters are as good or better than the pre-defined values. When they performed this task, known as timing closure, they assumed all IO slew rates were configured in fast mode. Which means we cannot guarantee the signals meet the values defined in the data sheet if slow mode is selected.
The errata is used to document unexpected behaviors that were not accounted for in initial documentation. We knew from day one, slow mode was not supported and the data sheet has always defined this at the beginning of the Peripheral Information and Timings chapter. Therefore, no plans to put this in the errata.
Please refer to the second paragraph of Section 5.1.1 in the data sheet. It states "The timing parameter values specified in this data manual assume the SLEWCTRL bit in each pad control register is configured for fast mode (0b)."
AM335x peripheral interfaces were only characterized with SLEWCTRL configured for fast slew rate, so all interfaces should be configured for fast slew rate.
Regards,
Sreenivasa
