i2c0 transfers cause bus errors - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85) +--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88) +--- Thread: i2c0 transfers cause bus errors (/showthread.php?tid=10672) |
i2c0 transfers cause bus errors - michaelanburaj - 07-14-2020 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. |