I’m experiencing some weird behavior I’d like to hear if anyone else has come across…
I have I2C-1 configured to run at 100KHz and I have an SHT-21 on the bus with address 0x40 and I have the R24 kernel driver loaded for this device (it also registers and finds the chip)
The weirdness is that for some unknown reason the two data bytes which comes after the clock stretching is “garbled” and always reads close to zero.
See image below (sorry for the bad paint job in merging the photo - see attached file jetson_stretching for better resolution) External Media
The oddity is that the SHT21 (Si7021 is what I’m using that is pin/function compatible) returns 0x00 and 0x20 as data bytes which is an illegal combination.
If I remove the Jetson module from my carrier board and attach an I2C debugger to the carrier and perform a read again I get a correct response: External Media
I do not have other I2C devices on my bus than the Si7021 (SHT21) when testing both scenarios which leads me to believe there’s something fishy going on with the Jetson as the I2C debugger can read the chip just fine.
Sadly this register is read only (it’s the humidity conversion result register) so i’m not able to write to it and all the registers that the chip has which are writable doesn’t use clock stretching
Do you happen to have some sort of software or hardware timeout in your I2C master code/peripheral that would “reset” in case the stretching takes longer than X miliseconds (as you see my device holds for 16-20mS)
It seems that the Jetson somehow “messes up” the communication…
I tried the scenarios from yesterday and added a new:
Scenario’s:
I2C debugger on carrier board w.o. Jetson module plugged in - this always works.
I2C debugger on carrier board w. Jetson plugged in but no communication on bus - this does not work
Jetson w.o. I2C debugger on carrier board - this does not work
In scenario 2 I’m using the debugger to talk to the SHT21 - which worked in scenario 1 and the Jetson is just sitting idle on the bus (also as a master) doing nothing.
This leads me to believe there’s some weirdness with the Jetson.
The slave address is 0x40 (or 0x80 if you count in the R/W bit) - I have no other parts on my bus.
Questions to nVidia:
Is there any other I2C parts on the module itself on the 3.3V I2C-GP1 bus?
----> if yes what is it and what’s their slave addresses?
Do you have any hardware or software timeout in the I2C module or kernel code?
I see you have some errata on multi master and fast mode plus for I2C - have you tested devices which uses hold mode? (clock stretching) perhaps there’s a bug in the hardware?
Hi, there is a device on I2C_GP1 in module which address is 0x40, you can find it in page 1 of carrier board schematic. Please change the address of SHT-21 to try again.
Sorry I didn’t mention this - I’m not using the development kit for the TX1 but a custom board that has only TX1 module and this SHT21 on it as the only device on the I2C bus hence I shouldn’t be affected by the INAxxx as it’s not on my board.
Can you check if there was any time out? - I see there’s some bus busy timeout stuff in the I2C peripheral could it be that arbitration is lost during the clock stretching due to this?
OK, that was not at all apparent to me when I designed my carrier board.
Please update your OEM Product design guide to reflect this information with the device addresses.
Also please add the note in there that multiple master and FM+ doesn’t work due to errata (that would also have been good to know in advance)
Does that mean that all these devices are inside the module and are they all on I2C-GP1?
TMP451 (Thermal) I2C Gen 1 : 7’h4C
ADS1015 (ACA detection) I2C Gen 2 : 7’h4A
INA226 (Power measurement) I2C Gen 2 : 7’h46
INA3221 (Power measurement) I2C Gen 2 : 7’h40
What about the mac address eeprom? - is that on I2C-GP0, I2C-GP1 or the I2C-PM bus?
is there anything else on the other busses (apart from MAC eeprom and the maxim PMIC)?
You can check the first page of carrier board schematic, the devices in module are listed under “P2180 I2C Port Assignments”, those on carrier board are listed under “P2597 I2C Port Assignments”. I2C-GP1 = I2C Gen 2, the eeprom is on I2C-PM (I2C Gen 3).
