i.MX8 MP I2C missing ACK

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX8 MP I2C missing ACK

Jump to solution
156 Views
aheck
Contributor II

Hello,

I am having an issue with I2C3 SCL being stuck low during the first transfer each boot.  I am using the i.MX8 MP EVK, with MCUXpresso SDK 2.15.  I am trying to talk to an I2C device via the I2C3 peripheral using the M7 while the A53 is parked in u-boot.

Immediately after boot, the first transaction appears to clock out the address byte, which is acknowledged, and the sub-address data to the slave device as expected. However, the sub-address ACK clock pulse is NOT being generated.  The ACK bit is not clocked when using either the I2C_MasterTransferNonBlocking() or the I2C_MasterTransferBlocking() commands, nor is a stop condition being generated.

Subsequent I2C transfers generate no clock pulses.  When in this state, if I reconfigure the SCL pin to an open-drain output, I can toggle it, so I do not believe the slave is holding the clock line low.

See the example waveform below.

aheck_0-1718045231581.png

Why would the first byte have a NAK clocked out correctly, but not the second byte?

 

0 Kudos
Reply
1 Solution
126 Views
pengyong_zhang
NXP Employee
NXP Employee

Hi, @aheck 

What I2C device is trying to connect? Is it 1.8V or 3.3V? At what speed?

I2C3 has a few other device on it, and it has an 3.3V level shifter (U5 or NTS0104GU12). If you connect 3.3V device, make sure the capacitive load is within level shifter's limit. Also, make sure u-boot is not occupying I2C3, or try to use another I2C, e.g. I2C5.

View solution in original post

0 Kudos
Reply
2 Replies
127 Views
pengyong_zhang
NXP Employee
NXP Employee

Hi, @aheck 

What I2C device is trying to connect? Is it 1.8V or 3.3V? At what speed?

I2C3 has a few other device on it, and it has an 3.3V level shifter (U5 or NTS0104GU12). If you connect 3.3V device, make sure the capacitive load is within level shifter's limit. Also, make sure u-boot is not occupying I2C3, or try to use another I2C, e.g. I2C5.

0 Kudos
Reply
119 Views
aheck
Contributor II
I believe the issue was with capacitive loading thanks to several jumper cables and solderless breadboards. Based on your reply, I hooked up the device to the 1.8 V I2C rails ("upstream" of U5), and I had no issues communicating with the device.
0 Kudos
Reply