I2C read - first byte garbage

t-gabor

I am trying to communicate with an Arduino Pro Mini 3.3V through the i2c interface with my Omega2+(latest firmware), and whenever I am reading from the arduino, the first byte is always wrong. This happens with my code, and also with some i2c samples flashed to the arduino. The same arduino and codes work correctly when reading with a raspberry pi.
Tried the command line i2cget and the I2C python library, same result. The first byte is not what it should be, but the rest of the data looks ok. When attaching an i2c lcd it seems to work correctly, and writes seem to work with the arduino too.
The Omega2+ is in the expansion dock and the i2c bus lines are jumper wires. Tried with and without pullup resistors(4K7). Unfortunately I have only one omega, I suspect it is a defect of mine.

Has anyone experienced this? Or any idea what could be wrong?

Chris Stratton

@t-gabor What is the expected data and what do your receive? Is is erroneous in both cases where the MSB should be a 1 and cases where it should be a 0, or only one of those? Does the data received depend on the data last written, either register address or device address?

4K7 is a bit high for the resistor unless it is in addition to something else, you might try 2K2 or placing two 4K7 resistors in parallel.

IIRC the MT7688 does not support clock stretching, it would be worth determining if the ATmega tries to do that - oscilloscope or logic analyzer investigation would be useful.

t-gabor

@Chris-Stratton The expected byte can be anything, I tried 0x00, 0xff and other random values.
The value I get is 17, always. And the data was correct from the second byte.
Unfortunately I have no access to an oscilloscope or logic analyzer.
I will try to change the device address.

t-gabor

@Chris-Stratton I changed the pull-up resistors, did not help.

The 3.3V Arduino Pro Mini runs at 8Mhz, maybe it is not fast enough to respond in time. I checked how the official arduino dock looks like, it seems it runs at 16Mhz.
Based on this assumption I tried to find out if I can slow down the omega2 i2c bus somehow, but I found no information how to do it.
During this investigation I saw the previous omega used a bit-banged i2c driver. This was implemented by the i2c-gpio-custom kernel module. After finding it is not part of the offcial omega2 repo, compiled the packages using the Docker Omega2 SDK(Thanks @José-Luis-Cánovas), and installed it on my omega2.

With the bit-banged i2c device my setup works correctly, the first byte is correct. As I have this workaround now, and I don't really have proper devices to analyze the problem further, I won't spend much time why the hw i2c bus is not working in my setup.

José Luis Cánovas

@t-gabor said in I2C read - first byte garbage:

After finding it is not part of the offcial omega2 repo, compiled the packages using the Docker Omega2 SDK(Thanks @José-Luis-Cánovas), and installed it on my omega2.

A pleasure.

t-gabor

These are the modules I used, for 0.1.10 b160. Installed them with opkg --force-depends
kmod-i2c-gpio-custom_4.4.46-2_mipsel_24kc.ipk
kmod-i2c-gpio_4.4.46-1_mipsel_24kc.ipk
kmod-i2c-algo-bit_4.4.46-1_mipsel_24kc.ipk

And I added this init.d script:

#!/bin/sh /etc/rc.common
# Creates bit-banged i2c-device /dev/i2c-1 on pins 5,4. 
# NOTE: This hides /dev/i2c-0!
 
START=98
STOP=97
 
start() {        
        omega2-ctrl gpiomux set i2c gpio
        insmod i2c-algo-bit
        insmod i2c-gpio
        insmod i2c-gpio-custom bus0=1,5,4
}                 
 
stop() {          
        rmmod i2c-gpio-custom
        rmmod i2c-gpio
        rmmod i2c-algo-bit
        omega2-ctrl gpiomux set i2c i2c
}