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.


RxBuf on the way in


RxBuf on the way out

Analyser capture:

enter image description here

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

The other problematic communication again the bit is squashed:

enter image description here

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="10 (buster)"

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.

1 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:




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: Failed I2C 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 I2C 2 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.

  • I was going to recommend changing the buadrate. From what Ive read, it looks like various versions of raspbian support different baud rates. allegedly, Pi3 supports 10K-500k baud, but im also seeing lots of user complaints, that only 10k, and 500k are functional in strech. Im curious, what happens if you set the buad rate to 500000
    – j0h
    Nov 19, 2019 at 0:04
  • from what i have read and using a scope to verify. Rpi3B+ i2c speed is fixed at 100kHz, no mater how to set the speed according to the official instructions.
    – tlfong01
    Nov 19, 2019 at 0:19
  • That is odd. It's almost as if the Pi is sampling the bit at the wrong time, but that is in the hardware so seems unlilkely. Glad it's sorted.
    – joan
    Nov 19, 2019 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.