[CV2][Evaluation] Does Tx1 platform support SMBus by I2C controller

precondition:
ROM version R24.2.1
Custom carry board
Operational:

  1. Porting SMBus battery.
    Problem:
    Does Tx1 platform I2C controller be compatible SMBus ?

I2C controller dose not support SMBus directly. Maybe you can use GPIO to simulate.

Can the I2C bus be set to 100 kHz data rate? I presume it can, because I2C devices exist that don’t do faster speeds.

Additionally, will the NVIDIA master keep the clock low for longer than a few milliseconds? I don’t see why it would, but you never know.

Finally, do you need the ability to reset the SMBus? (That is, hold clock low for the reset timeout?)

If all you need to do is communicate with an existing slave with a known address, and that slave happens to be specified as “SMBus,” but you can qualify that the slave doesn’t do something crazy like force the bus low forever, then it should totally be possible to talk to the SMBus slave from the Jetson and make it robust.

Finally, if you really need the “alert” function then that could be read as a GPIO.

It all depends on how crazy the SMBus device is …

@Trumany

As snarky said, 100KHz clock take 0.01ms delta T.
Could the jetson tx1 gpio run so fast?
Normally gpio can be delay 1ms, and Linux can’t keep the timming as 1ms level.

And

I think Jetson TX1 i2c controller can support SMBus.
There is a reference design show that TX1 support bq24735 charger. But bq24735 only have SMBus.

https://devtalk.nvidia.com/default/topic/993666/?comment=5083716
http://developer.nvidia.com/embedded/dlc/jetson-tx1-module-battery-and-charger-design-guide

SMBus has some special cases that are maybe not supported by the i2c controller.
The two that I know about are the timeout-reset behavior, and the separate alert signal.
If you don’t need/use/run into the timeout condition, and if you don’t need alert, or emulate alert using GPIO, then you should be able to talk to SMBus devices robustly.

However, I don’t think NVIDIA will ever say “it works as SMBus” because those cases (especially the timeout reset) may matter to someone, and that’s just not going to work right.
So, if your goal is “talk to this specific battery,” then you should try doing so with I2C, and validate yourself that the timeout reset behavior isn’t needed, and that the alert signal isn’t needed (or that you can emulate it using GPIO.)
At that point, the decision to declare “this works” and ship to customers lies on you, not on NVIDIA, so they’d probably be totally OK with that. What they can’t do is say “Jetson can do SMBus,” because, to be 100% technically correct (which is the best kind of correct!) it doesn’t.

Hi Snarky:

Thanks. We want use this bus to connect charger and battery.
We should communicate charger and battery IC vendor, Whether there is an alternative solution。

Are you a Nvdia engineer?

No, just an interested hacker :-)

Hi Snarky & Trumany :

I am afraid that the Electrical signal don’t match the IIC.

http://www.smbus.org/faq/faq.htm
DC Electrical Specifications:
VIL, MAX = 0.8 V (0.6 V in rev. 1.0)
VIH, MIN = 2.0 V (1.4 V in rev. 1.0)
ILEAK, MAX = ±5 µA (±1 µA in rev. 1.0)

Hi zuoqiang,

The frequency range of SMBus is 10K~100Khz, there is a I2C-GPIO driver in linux which could be used to simulate I2C.

And yes as you said, although they are mostly compatible, there are still several differences between SMBus and I2C. The most important one is the VIH level, it is requested >2.1V for SMBus. So only 3.3V or higher pull-up (or adding a level shift) could meet SMBus and I2C simultaneously.