[FAQ] AM62A7 / AM62A3 / AM62A1-Q1 and AM62D-Q1 Custom board hardware design – I2C interface

Part Number: AM62A7
Other Parts Discussed in Thread: AM62P, AM62A3, AM625-Q1, AM620-Q1, AM625, AM625SIP, AM623, AM6442, SK-AM64B

Hi TI Experts,

I have the below queries regarding the I2C interface

  1. Need information on the number of I2C interfaces available
  2. Termination of I2C interfaces when used as I2C interface and not used as I2C interface.
  3. Any additional recommendations / Guidelines
  4. Any concerns on Interfacing SoC Non-Failsafe I2C to devices that are powered before the SoC- Ex PMIC
  5. Any exception that are required to be considered when using the I2C interfaces. 
  6. Can the I2C interface be used to interface with devices supporting SMBus or PMBus 

Let me know your thoughts.

  • Hi Board designers, 

    Refer below inputs for the I2C interface related queries.

    1. Need information on the number of I2C interfaces available

    The device contains six multicontroller Inter-Integrated Circuit (I2C) controllers. Each I2C controller was designed to be compliant to the Philips I2C-busTm specification version 2.1. However, the device IOs are not fully compliant to the I2C electrical specification.

    Open Drain buffer type I2C interface - MCU_I2C0 and WKUP_I2C0

    These I2C interfaces are Open drain type I/Os. These I2C interfaces are fail-safe IO terminals.

    The rise and fall times of the I2C signals connected to these ports must not exceed a slew rate of 0.08 V/ns (or 8E+7 V/s). This limit is more restrictive than the minimum fall time limits defined in the I2C specification. Therefore, it may be necessary to add additional capacitance (RC) to the I2C signals to slow the rise and fall times such that they do not exceed a slew rate of 0.08 V/ns.

    Refer below 

    AM62A7 Reference 

    Reference: AM62P SK schematics

    LVCMOS buffer type I2C interface - I2C0, I2C1, I2C2, and I2C3

    These I2C interfaces are LVCMOS IO types. LVCMOS IOs being used on these ports are connected such they emulate open-drain outputs.

    1. Termination of I2C interfaces when used as I2C interface and not used as I2C interface.

    Open Drain buffer type I2C interface - MCU_I2C0 and WKUP_I2C0

    Refer Pin Connectivity Requirements in the datasheet.

    These interfaces are recommended to be terminated when configured as I2C or as GPIO. When the IO is configured as input and being driven by a push-pull input from power-up the termination can be depopulated

    LVCMOS buffer type I2C interface - I2C0, I2C1, I2C2, and I2C3

    When configured as I2C interface, pullups are recommended. Since these IOs are LVCMOS type, the pullups are recommended to be connected with the shortest stub. When configured as GPIO, based on the use case an external pull can be provided or the internal pulls can be used.

    1. Any additional recommendations / Guidelines

    I2C3 has one or more signals which can be multiplexed to more than one pin. Timing is only valid for specific pin combinations known as IOSETs. Valid pin combinations or IOSETs for this interface are defined in the SysConfig-PinMux Tool.

    Refer below section of the device specific datasheet.

    7.6.1 I2C Open-Drain, and Fail-Safe (I2C OD FS) Electrical Characteristics

            4. Any concerns on Interfacing SoC Non-Failsafe I2C to devices that are powered before the SoC- Ex PMIC 

    Are the attached PMIC IOs true open-drain I2C IOs?  If so, are the pull-up resistors associated with this I2C port powered by the same power supply that is used to power SoC I2C Example I2C0 IOs?  We should not have a fail-safe problem if the answer to both questions is yes.

     Is there anything else connected to these I2C signals that could source a potential to the I2C0 pins before the IOs are powered? 

    We are only concerned with fail-safe if there is a possibility for the attached devices to apply a potential to the SoC IOs before they receive power.  We do not have any fail-safe concern if that is not possible.

            5. Any exception that are required to be considered when using the I2C interfaces. 

    Refer section 7.9.2.12 I2C of the data sheet.

    Read through the Exceptions section for I2C0, I2C1, I2C2, and I2C3 + Exceptions section for MCU_I2C0 and WKUP_I2C0

    Note: 
    Refer below documents during the I2C interface design.

    Hardware Design Guide for AM62A7 / AM62A3 Devices

    https://www.ti.com/lit/an/sprad85/sprad85.pdf

    AM625 / AM623 / AM625SIP / AM625-Q1 / AM620-Q1 / AM62A7 / AM62A3 Schematic Design and Review Checklist

    https://www.ti.com/lit/an/sprad21b/sprad21b.pdf

            6.Can the I2C interface be used to interface with devices supporting SMBus or PMBus 

    The I2C module implemented in these processor families does not support SM Bus or PM Bus

    Regards,

    Lavanya M R.

  • Hi Board designers, 

    Refer below inputs for  I2C pullup calculation
    www.ti.com/.../slva689.pdf

    The board designer is responsible for selecting a pull-up value that meets the rise time requirements for their specific system implementation.
    The I2C signal trace capacitance will vary based on their PCB design which means the pull-up value may need to be adjusted to achieve the appropriate rise time. A large pull-up value will produce a slow rise time, that will be easy to pull below VIL max. A small pull-up value will produce a fast rise time, that may be difficult to pull below VIL max. The I2C standard defines a range for the expected rise and fall times. However, some of the devices being connected to the I2C signal may have their own requirements and characteristics.
    For example, our I2C ports implemented with the “I2C OD FS” IO cells have a very restrictive maximum input slew rate when operating at 3.3V and this limit
    needs to be considered when selecting a pull-up resistor value. Another example, our I2C ports implemented with the “LVCMOS” IO cells will violate the minimum fall time defined in the I2C standard when driving the signal low. Note: This last example is not a function of pull-up value and was only mentioned for completeness. The board designer must also consider the output drive strength of each device driving the I2C signal to ensure it is able to pull the signal low enough for it to be considered a valid logic low for each device connected to the signal. Some devices may not be able to pull the signal below the lowest VIL max of the attached devices if the pull-up value is too small.

    Regards,

    Sreenivasa

  • Hi Board designers, 

    The current circuit diagram is as shown in , and if there are no issues with this, I would like to proceed as is.

     We have updated or will be updating the pin connectivity requirements to allow the unused open drain I2C interface to be connected to VSS through a resistor. Customer connected  the unused open drain interface directly to ground on their board.

    Any thoughts?

    This is okay since the IO cell is implemented with a true open-drain output buffer. Therefore, it is not possible for these pins to be driven high.  So there is no chance of contention.

    This should not be done with the I2C ports (emulated I2C) that use LVCMOS or SDIO IO cells since these IOs are implemented with push-pull output buffers that may accidently be driven high.

     Regards,

    Sreenivasa

  • Hi Board designers, 

    Refer below inputs on I2C current:

    "I2C OD FS" and "LVCMOS" using I2C exist minimum output current specification, but not exist maximum specification.
    What value is the maximum output current specification?
    I have a additional question. When I use Pin C18 / B19 as I2C1, Is the output current specifications of Pin C18 / B19 same to "LVCMOS"?

    We indirectly define a maximum output current, by defining our minimum current which the output buffer can sink or source while maintaining a valid Vol or Voh. I will try to explain below.
    We define a maximum low output voltage and a minimum high output voltage. These values are typically set to industry standard values. The output buffer will have internal voltage drop that increases as output current increases. At some point the voltage drop in the output buffer will cause the voltage to rise above the maximum Vol or drop below the minimum Voh limits defined in the datasheet. The actual output current where this occurs varies from one device to another due to Process, Voltage, and Temperature (PVT) differences. Therefore, we define the minimum value of this output current range in the datasheet that will always provide a valid Vol and Voh. These parameter are named Low Level Output Current and High Level Output Current in the datasheet.
    These minimum output current values defined in the datasheet actually defines the maximum output current your product should expect for maintaining a valid Vol or Voh across all PVT variations.


    I didn't see your other question until I sent my first reply. Yes, pins C18 and B19 are implemented with LVCMOS IOs.
    The Buffer Type column in the Pin Attributes table can be used to determine which IO type was implemented for a specific pin.
    Note: I2C ports implemented with LVCMOS IOs will not be fully compliant to the I2C specification. Only I2C0 and MCU_I2C0 ports are implemented with the I2C OD FS IOs, which are compliant to the I2C specification.

    I understood the minimum output current specification. Regarding 2nd question,
    Is it correct that the low level output current specifications of Pin C18 / B19 as I2C1 is 5mA ?

    Yes. It is 5mA when operating at 3.3V , and 3mA when operating at 1.8V.
    FYI, I added a note to each Electrical Characteristic table that explains the IOL and IOH parameters. See the note below.
    The IOL and IOH parameters 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. 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.
    Hopefully, the note above will clarify what is being defined by these parameters.

    Regards,

    Sreenivasa

  • Hi Board designers, 

    Refer below regarding I2C interface clock frequency 

    Refer to the Pin Connectivity Requirements section of the processor-specific data sheet. A pullup (4.7kΩ, adjust after testing) is recommended. When do i adjust the pullup.

    The I2C interface pullup and the capacitive loading affect the I2C clock slew.

    In use cases where the measured clock frequency does not match the configured clock frequency, the recommendation is to adjust the pull (stronger pullup - reduce value) and measure the clock frequency.

    Regards,

    Sreenivasa

  • Hi Board designers, 

    Refer below regarding I2C slew rate control RC

    AM6442: SK-AM64B purpose of RC filter

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1362478/am6442-sk-am64b-purpose-of-rc-filter

    RC filter cutoff frequency is 338KHZ with 4.7K pullup, 62E series resistor and 100pF. and I2C operating frequency is 400KHZ. Thus I2C signal not reach to 3.3V lavel.

    We used 4.7K pullup, 62E series resistor and 10pF. and not observer any concern on VIL & VIH. 

    Does TI have any concern with 4.7K pullup, 62E series resistor and 10pF? if not then we are ok to go...

    Below is requested data. 

    Regards,

    Sreenivasa

  • Hi Board designers, 

    Refer below regarding I2C clock stretching

    https://www.ti.com/lit/an/sbaa565/sbaa565.pd

    6.2 Clock Stretching In some I2C target devices, there are situations that the target device controls the SCL serial clock. In those cases, the target device can slow down the communication. This process is known as clock stretching. In general, the SCL line and therefore the I2C clock rate, is controlled by the controller. However, there are instances where the target device is unable to comply with the clock rate. For example, the target device requires extra time to process a command or send data. In such cases, the target device can slow down the communication through clock stretching.

    The clock stretching depends on the Bus capacitance.

    In case the measured speed does not match the set I2C speed, verify the I2C clock slew and adjust the slew by varying the pullup on the I2C bus.

    Regards,

    Sreenivasa

  • Hi Board designers, 

    Inputs related to testing HS mode in I2C 

    The design team is looking to test open drain I2C interface for Hs-mode (up to 3.4Mbits/s) using the SK
    – 1.8V

    On the SK VDDSHV_MCU is Connected to 3.3V
    If the MCU_I2C0_ open drain output signals are pulled to 1.8V (with the IO supply VDDSHV_MCU connected to 3.3V), would it be possible to test the I2C interface for HS-Mode

    In the data sheet does the below 1.8V and 3.3V indicate IO supply for IO group supply or the supply connected to the open drain output
    MCU_I2C0 and WKUP_I2C0
    – Speeds:
    • Standard-mode (up to 100Kbits/s)
    – 1.8V
    – 3.3V
    • Fast-mode (up to 400Kbits/s)
    – 1.8V
    – 3.3V
    • Hs-mode (up to 3.4Mbits/s)
    – 1.8V

    This will not work. The IO would see the 1.8V signal as a mid-supply voltage on its input buffer. This is definitely not allowed.

    I thought so based on the electrical characteristics but wanted to get your thoughts.
    I am not sure on the advantage the I2C open drain output provides ?
    Is changing the VDDSHV_MCU to 1.8V the only option to test HS mode or did you have some thoughts.

    The I2C OD FS buffer type doesn’t violate the fall time requirement defined in the I2C standard and it allows up to 3.4Mbits/s data transfer as long as you power the IOs from a 1.8V supply.

    Yes, the only way you can expect the I2C instances, which implement the I2C OD FS buffer type, to operate in Hs-mode is to apply 1.8V to the VDDSHV_MCU power rail.

    Regards,

    Sreenivasa

  • Hi Board Designers,

    Refer below inputs related to WKUP_I2C0 and MCU_I2C0 speed of operation 

    • I2C bus is open-drain LVCMOS I/O buffer.
    • I2C bus has voltage of 3.3v pull up voltage.

    Question:

    As per the following sentence in TRM of AM62A (SPRUJ16B – DECEMBER 2021 – REVISED AUGUST 2023 / Section: 12.2.2.1.1 I2C Features):

    • Supports HS mode (up to 3.4 Mbps) only for instances with true open drain buffer and in 1.8 V mode

    Does our case can benefit from the higher speeds like 1Mbps?

    Please refer below.

    Based on the data sheet this is not allowed.

    Hopefully, you are applying 3.3V to the VDDSHV_MCU IO power rail since you are pulling the signals up to 3.3V and the “I2C OD FS” buffer type associated with the WKUP_I2C0 port is not 3.3V tolerant when operating at 1.8V.

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

    As Sreenivasa pointed out in his previous post, the “I2C OD FS” buffer type associated with the WKUP_I2C0 port only supports data transfer rates up to 400kbits/s when operating at 3.3V. You would need to operate the WKUP_I2C0 IOs at 1.8V to support 1Mbps.

    Thanks a lot for your confirmation, may I ask what will happen if I configured the I2C peripheral to be 1MHz, will it reject my settings/configuration and will operate in 400KHz if the bus was 3.3v?

    I mean what will happen on the level of the IP itself:

    • Would it ignore my settings?
    • Would it apply my settings and then I2C operations will be erroneous?

    Rationale from the question is that we have observed that I2C is working on 400KHz even though we have configured it to 1MHz. We are double checking that out settings has been affected, but I'd like to know your expectations.

    We do not recommend or support any attempt of trying to operate the device outside the limits defined in the datasheet.

    From my understanding the max speed limitation is related to the IO cell design, not the I2C module. The I2C module doesn't know the voltage applied to the IO power rail, so I would have expected it to attempt to communicate at 1MHz. However, there may be some software functions that limits the speed based on the IO operating voltage defined in your system configuration file.

    Regards,

    Sreenivasa