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

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 FAQ.

Can we change I2C pu power rails?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1215114/tda4ve-q1-can-we-change-i2c-pu-power-rails/4594227?tisearch=e2e-sitesearch&keymatch=userdisplayname%253A%2522Robert%2520Eschler%2522%2520%2526%2526%2520buffer#4594227

 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

Hi Board Designers,

FYI.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1581689/am6422-clarification-on-i2c_bufstat-usage-rxstat-vs-txstat-behavior-in-controller-receive-mode 

Please refer inputs i received from the design team:

I2C is configured as master receiver for 7 bytes.

From spec:

TXSTAT = DCOUNT – TXFIFO. Note: This DCOUNT gets decremented during FIFO operations.

RXSTAT = Number of received bytes currently present in RX FIFO and not yet drained by CPU read.

From simulation:

Case 1: DCOUNT = 7, TXFIFO is empty

Received 7 bytes and RDR is set due to Stop condition.

Read BUFSTAT : RXSTAT = 7 as 7 bytes received, TXSTAT = 7

Read 1 byte: Read BUFSTAT : RXSTAT = 6 as 7 bytes received, TXSTAT = 6

Read 2 byte: Read BUFSTAT : RXSTAT = 5 as 7 bytes received, TXSTAT = 5

….

Read 7 bytes: Read BUFSTAT : RXSTAT = 0 as 7 bytes received, TXSTAT = 7

Note: Internal DCOUNT counter reloads with configured original DCOUNT register value once it reaches 0.

Conclusion:

RX STATUS value depends on the current number of received bytes. It becomes 0 with all bytes read.

TX STATUS as shown above is dependent on the DCOUNT – TX FIFO.

Regards,

Sreenivasa

Hi Board Designers,

FYI, collaterals related to I2C

I2C interface related collaterals
www.ti.com/.../sbaa565.pdf
1.2 I
I2C Speed Modes
https://www.ti.com/content/dam/videos/external-videos/es-mx/8/3816841626001/6235789966001.mp4/subassets/basics-of-i2c-the-i2c-protocol-presentation.pdf

look for fast-mode plus
https://www.ti.com/content/dam/videos/external-videos/ko-kr/8/3816841626001/6243124608001.mp4/subassets/adcs-introduction-to-i2c-advanced-topics-presentation.pdf

www.ti.com/.../slyt770.pdf
I2C Bus Pullup Resistor Calculation
www.ti.com/.../slva689.pdf
https://www.ti.com/lit/an/slva695/slva695.pdf

Regards,

Sreenivasa 

Hi Board Designers,

Inputs related to configuring I2C interface for HS mode

we have captured the data with Slave device (TMP1075) and we were getting 0x4B data while reading the register, so we were able to communicate with the slave at 1Mbps, but we are getting the spikes at the starting of the clock but when we tested at 400kHz there was no spike observed.

Please refer the below images for your reference.

Result at 400KHz

Result at 1MHz

For I2C bitrate calculation:

Formula is HS bit rate = clk/(HSSCLL+7+HSSCLH+5)
Formula is FS bit rate = clk/(SCLL+7+SCLH+5)

The value of clk = 96 MHz

For 1MHz below values are used:
PSC = 0, SCLL = 115, SCLH = 113, HSSCLL = 41, HSSCLH = 43

For 3.4 MHz, the below values should be used
PSC = 0, SCLL = 115, SCLH = 113, HSSCLL = 12, HSSCLH = 5

After making changes to the software (i.e. by properly configuring the SCLL and SCLH register for FS and HS speed) the I2C waveforms are now cleaner, and no spikes are observed when tested on HS Mode(i.e. 1MHz).

After making software changes for I2C, we able to communicate with the device at 1MHz and getting the clock without spikes.

Registers

Regards,

Sreenivasa