Hi,
I am trying to have I2C connection established between the Jetson Nano (master) and TI Launchxl-F280969 board (slave). When I run “sudo i2cdetect -y 1” command, it scans different addresses pretty fast and when it gets to the slave address (in this case 0x20), it takes 2-3 seconds and the it cannot detect the address. After this address, it scans other addresses very slowly. I have tried different addresses on slave and everytime Jetson is stuck at the slave address.
I have two Launchxl-F280969 boards and they can communicate pretty well over I2C. However they required to have pull-up resistors on SDA and SCL. I tried 1kohm PU between Launchxl-F280969 and Jetson but it didn’t help.
I guess Jetson tries to call for a device on each address and if it doesn’t see AKC it jumps to the next, so I don’t know what happens that it’s not able to detect the device when it gets to the address.
–Kash
Hi, what’s the voltage level of I2C of Launchxl board? Did you use a oscilloscope to observe the I2C waveform when reading devices?
Hi Trumany,
The voltage level of LAUNCHXL is 3.3v and it’s connected through a USB cable to the Jetson.
Yes, I ran some tests yesterday and took screenshots. I changed the slave address to 0x03 (the first address i2cdetect checks) to capture the issue. When the LAUNCHXL is not connected, this is what I get (SDA yellos, SCL blue):
when the LAUNCHXL is connected, this is what I get:
So apart from the voltage level that jumps to 3.3v for logic high, the ACK bit is set and bus is pulled down after the transmission. If I understand the I2C protocol correctly, the ACK bit is set by slave (LAUNHXL) and Read/Write bit is set by master, so in this case Read/Write=1 and ACK=1 which means the slave is supposed to send data and that’s the reason the bus is pulled down by slave, but apparently slave is not sending anything after that.
Not sure if my assumptions are right.
–Kash
Are you using I2C2? It is 1.8V port not 3.3V, please use other I2C, like I2C0 or I2C1 to test.
I’m using I2C1 (pin3 and 5).
Why is it 1.8v without device attached in your first capture? I2C1 should be 3.3V level.
I don’t know, that’s a problem. What I can do is to run the same test on I2C0 and take screenshots.
On a separate note, when the ACK bit is set by slave, shouldn’t the master (Jetson) send any data?
Trumany,
The F28069 I2C module can hold SCL low while the intervention of the device is required after a byte has been transmitted. This is the same case here as Read/Write bit is set by master (Jetson) and ACK bit is set (zero) by slave (F28069) in the last two pictures. So in this case I think the slave should provide data for master and I know my software does not send any data, now the question is what data should slave send when its address is called by Jetson?
Thanks,
In general slave gives ACK to host and then host can start to read info in slave device, so it depends on what you want to read from slave.
I am still confused by the 1.8v voltage on I2C1 in your screenshot. Can you share the photo of which I2C1 pins on board you probed?
Unfortunately I don’t have access to oscilloscope for these days, but here is the picture of the wiring:
I’ll do the oscilloscope measurement on I2C bus0 by end of this week.
But if the slave is going to send data, shouldn’t the SCL come from Jetson (master)?
The pins are correct as I2C1.
SCL is always from master, the slave will feedback data only if master send out command/register address. Please read the I2C spec and data sheet of your I2C device for more info.
Trumany,
I guess I understand the issue. The master sends the slave address with read request (read/write bit equals one), then slave sees the address and does ACK. Now master pulls the SCL bus low to show the end of transmission. So far so good, the issue here is slave holds the SCL bus low but does not send data. based on my device datasheet, slave can do that:
But in order to release the SCL bus, slave should put a data in I2C_TX buffer and send it out. I can manually do that, but I don’t know what value master is supposed to see when I2Cdetect command finds a module on the bus.
I don’t think it needs manually to send data from slave device. I believe there should be some commands (registers address) in datasheet of slave device. The master only needs to follow that to send out command, then slave device will send back some data automatically.
