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.
Why would the first byte have a NAK clocked out correctly, but not the second byte?
Solved! Go to Solution.
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.
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.