I2C works but gives wrong value

Question

I have an RPi3b (Master) wired up to an MCU (Slave) communicating via I2C. I did have an RPi1b wired up and upon which I did my first development (cheaper to accidentally fry). Suddenly I'm getting a problem. There are three communications where this happens and it seems to be the first byte 'read'.

I'm expecting 1 or 0 in a uint8_t. I'm getting 129 or 128.

On another communication I'm expecting 20 but I'm getting 148.

In another I read the bits of the first byte as flags and the most significant is always 1.

All occasions 128 higher, the most significant bit is 1. So far only seen on the first byte to be read.

I've checked the wire and the correct HEX value is read (0x14). Somehow between the wire and my read(fd, &RxBuf, 1) it gets changed into 148.

Before

After

Analyser capture:

I've marked the problem bit and I notice that it is squashed.

The other problematic communication again the bit is squashed:

It might be that despite my analyser reading this a 0 the Pi is reading it as a 1. I have no idea how to correct this. It only became a problem when I switched to the RPi3. Is there something I'm missing?

Other things that might make a difference:
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Static hostname: octopi2
Icon name: computer
Machine ID: d38dfc478d9b4f6b9dd12af98867d7c1
Boot ID: c7c35223be9846fda7907464a622284d
Operating System: Raspbian GNU/Linux 10 (buster)
Kernel: Linux 4.19.75-v7+
Architecture: arm

Many thanks in advance.

Answer 1

I initially amended everything to put out a dummy first byte and then just started at the second one. This worked but I was not happy with it. Trawled the internet lots more. Tried many things. No difference. Noticed that compared to the MCU downstream communications, the I2C to PI was very slow. About half the speed. Editing /boot/config.txt and amending:

dtparam=i2c_arm=on

to

dtparam=i2c_arm=on,i2c_arm_baudrate=200000

Did the trick. I tried 400000 at first but it was too fast. The MCU is only clocked to 8Mhz and cannot respond to rapid calls at that speed. 200 strangely brought it in line. No more squashed bit.

Hope this helps someone who stumbles across the same situation.

Edit - @j0h (comments below) - The outcome of different values:

At 200000 everything is stable. At 400000 some things fail: You can see the second I2C bus on the MCU (second down). There is a difference in the timing (width) of the communications. I have highlighted a failed read. The MCU was not ready to acknowledge. At 500000 same story: Failed to read again.

Having said that I can make a successful communication at 500000 if it is while the MCU is not doing anything else and it is not too complex i.e. one byte each way. To keep it stable 200000 seems best.

Interestingly I have not been able to recreate the original issue with this baudrate setting. Absence yes, it will happen, but with any setting the squashed bit is gone. The speed of the communication from there seems highly dependant on what the MCU can reliably respond to.

Even down at 5000 the communication is ok. It also looks like there is a lower limit i.e. 5000 looks the same as higher figures. Maybe there is a hard coded minimum somewhere.

All fun :) Thanks for the responses.