Colibri imx6ull, i2c protection and bus recovery

Hi there,

We have a coulomb counter (Analog Devices LTC2944) attached to a Li-Ion battery pack, and this is monitored by the Toradex Colibri iMX6ULL, connected on pins 194, 196. The Colibri module power comes from a 3.3V buck converter (TI LMZM23601V3). There are other devices on the I2C bus which are mentioned at the end of the email. The only master device on the bus is the Colibri module.

The prompt for this inquiry is that we have observed some I2C lockup conditions from a large number of units in the field. This lockup condition blocks communications on the whole I2C bus, and is resolved (at least temporarily) by the supervisor chip power power cycling the device by disabling the 3.3V buck converter temporarily. At this stage we believe that it is related to the units having been placed in shipping mode for a few days before being installed and activated.

Under shipping mode conditions, we disable the 3.3V buck converter. The coulomb counter is however still supplied from the battery pack. It has some gentle pull-ups on the SDA and SCL lines (2V, 50uA according to the datasheet.)

We wish to understand if there is any impact on the Colibri module being back-powered on its SDA and SCL pins. The information that I can find is a little confusing, perhaps you can enlighten us?

The Colibri module datasheet in the Absolute Maximum Ratings section gives the Vmvax_IO as 3.6V regardless of the supply voltage state.

On the face of it, this appears to contradict the IMX6ULLIEC rev1.2 data sheet where page 22 shows the Vin/Vout maximum voltage as OVDD+0.3V.

Is this difference due to the undervoltage lockout circuit on the Colibri module?

Assuming there is no circuit on the Colibri module to protect the IOs, this means that we may be technically exceeding the OVDD+0.3V limit. We are hopeful though that the low current will eliminate any risk of damage. The IMX6ULLRM rev1 Reference Manual on page 1351 shows a little more information on the input cell; there appears to be a series resistor which would limit the current into the pin before the clamp circuit. The IMX6ULLIEC datasheet doesn’t show a value for this but there is a value given for R_Keeper (105kOhm – 175kOhm) … do you know if this is the same?

Full list of devices on the I2C bus:

  • 2x Microchip PAC1934, powered from 3V3 rail
  • Two sets of 10k pull ups to 3V3
  • Analog LTC4162-L, connected to Li-Ion pack and charging input, DVcc=3V3 rail
  • Dialog Semi SLG46826V, powered by an independent 3.3V reg from battery pack
  • Analog LTC2944, connected to Li-Ion pack
  • Colibri IMX6ULL SoM, powered from 3V3 rail (pins 10, 12, 40, 42, 84, 108, 148, 182, 198, 200)

On a similar point: I am finding it difficult to find any reliable information on whether or not i2c-core.c implements bus recovery automatically, or if more needs to be done? The device tree does include the relevant gpio section in the relevant i2c entry:

&i2c1 {
	status = "okay";
	clock-frequency = <100000>;
	pinctrl-names = "default", "gpio";
	pinctrl-0 = <&pg_sen101_i2c_monitor>;
	pinctrl-1 = <&pg_sen101_i2c_monitor_gpio>;
	sda-gpios = <&gpio1 28 GPIO_OPEN_DRAIN>;
	scl-gpios = <&gpio1 29 GPIO_OPEN_DRAIN>;

Greetings @lblackbeard,

I believe the 3.6V figure for Vmax_IO on the Colibri iMX6ULL datasheet assumes an OVDD value of 3.3V.

I’ve never personally seen these lockup issues due to backfeeding on the I2C lines. What is the voltage of this battery pack when in shipping mode? How is your battery pack interfaced to the Colibri power supply and your buck converter? I’ve seen the description of the ICs you’re using but perhaps you can share an schematic?

Note that you can tick the private option when replying so just Toradex staff can have access to it.