07-14-2020, 02:25 PM
Hello,
the rock64 i2c-0 when trying to quick check discover connected devices (quick read, byte read, both), does send on occasions following the NACKed address byte a 2nd start condition and stop immediately, then another 3rd start before next transfer [see the attachment], that starts with the next device address. the additional 2nd start before the stop is bothering a STM32 slave sitting on this bus (additional data point a LPC controller does not get affected). While he STM32 seems sensitive to such errors (BERR) and causes lock-up, I am interested in knowing why does the rock64 do this.
the code looks like this:
for(i=0; i<128; i++)
{
ioctl(I2cSlave, I2C_SLAVE, i);
// i2c_smbus_write_quick(I2cSlave, I2C_SMBUS_WRITE);
rc = i2c_smbus_read_byte_data(I2cSlave, commad_word);
the bus is run at 100KHz, i even tried adding a delay in the loops for 100ms, still does not help. is there a setting in device tree or in rockchip's i2c registers to prevent this from happening? If this is not normal could some other hardware/software muxed on the port pins be causing this?
[attachment: 1 NACKd-address in the capture is a normal one, that ends with a stop and the next start condition starts the next transfer. the 2nd NACKd-address ends with a added 2nd start, then stop, followed by a start for the next transfer]
Thanks,
-Michael.
the rock64 i2c-0 when trying to quick check discover connected devices (quick read, byte read, both), does send on occasions following the NACKed address byte a 2nd start condition and stop immediately, then another 3rd start before next transfer [see the attachment], that starts with the next device address. the additional 2nd start before the stop is bothering a STM32 slave sitting on this bus (additional data point a LPC controller does not get affected). While he STM32 seems sensitive to such errors (BERR) and causes lock-up, I am interested in knowing why does the rock64 do this.
the code looks like this:
for(i=0; i<128; i++)
{
ioctl(I2cSlave, I2C_SLAVE, i);
// i2c_smbus_write_quick(I2cSlave, I2C_SMBUS_WRITE);
rc = i2c_smbus_read_byte_data(I2cSlave, commad_word);
the bus is run at 100KHz, i even tried adding a delay in the loops for 100ms, still does not help. is there a setting in device tree or in rockchip's i2c registers to prevent this from happening? If this is not normal could some other hardware/software muxed on the port pins be causing this?
[attachment: 1 NACKd-address in the capture is a normal one, that ends with a stop and the next start condition starts the next transfer. the 2nd NACKd-address ends with a added 2nd start, then stop, followed by a start for the next transfer]
Thanks,
-Michael.