Strange behaviour in I2C baud rate - RPI2-B / PRI3

Question

I am trying to connect a stm32 with RPI3 (Raspbian Jessie) over I2C and scoping the I2C lines with an oscilloscope. I am using wiringPi library. I set the baud rate to 400k and after few seconds the baud rate drops down to 250k. Same Behaviour happens with 100k/200k rate (drops down to 60k and 120k after few seconds).

The interesting thing I discovered is, when ever there is load on RPi (like running a 1080p youtube video and etc.) the baud rate increase back to normal values (250k->400k or 60k->100k). (Same problem also occurs with RPi2-B)

What am I missing here? Why I2C baud rate is not fixed and related with the load on the RPI?

Answer 1

What am I missing here? Why I2C baud rate is not fixed and related with the load on the RPI?

I'm not sure, but based on what you are saying about the fact that it doesn't happen under load, I'd guess it may be because the baud rate is tied to processor frequency, which is governed by the OS.

Check the output of the following:

export cpufdir=/sys/devices/system/cpu/cpufreq/policy0
cat $cpufdir/scaling_governor
cat $cpufdir/scaling_available_governors

The first cat will probably say ondemand; the second will return that and some other choices including performance.

There are other nodes in that directory which will tell you the current frequency (scaling_cur_freq) and the min/max possible (check ls $cpufdir).

Set the governor with:

sudo sh -c "echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor"

I didn't use $cpufdir because I'm not sure that shell variables will necessarily get passed through with sudo (personally I prefer su and that's what I mostly use). Anyway, you if you check the governor now it should be that, and the current frequency should equal the maximum frequency.

For more information see here.

If that works, then this was the case of the problem.

Answer 2

The wiringPi library appears to use the hardware I2C busses, not just GPIO bitbanging.

The hardware I2C busses have their clocks derived from the VPU clock, also called the bus clock, and divide down from that to produce the I2C bus clock. The Raspberry Pi firmware changes that bus clock behind Linux's back (for example due to over-thermal or under-voltage), giving Linux no chance to fix up the dividers for clocks derived from that bus.

I think if you did a watch on /debug/clk/clk_summary (assuming you have that file -- it was disabled in the downstream kernel tree last I checked) you'd see the vpu clock dropping when you see your performance drop.