Raspberry Pi Forums

Does the I2C driver give accurate clock frequency for you? It doesn't for me.

I'm testing the I2C functionality (using an Aardvark as an I2C slave, a Pi 3 as the master, a Saleae watching the lines, and some C code I'm putting together). Write and read work fine but the clock frequency is much lower than I'm asking for with /etc/modprobe.d/i2c.conf.

I set 100KHz and I get 62.5 KHz (62.5% of expected). I set 650KHz and I get 406KHz (62.5% of expected).

Is there some system clock configuration that has changed for the Pi3 that might have thrown the clock frequencies off?

I notice the datasheet says the typical IO bus clock is 150 MHz. I see people talking about 250 MHz and 500 MHz for some of the Pi clocks. 150 MHz to 250 MHz is 60%

It makes me thing I have a clock set wrong but I have no idea what or where.

I agree! I am running on the Raspberry Pi Compute Module 3, and I see the same thing (verified with a scope). I'm using I2C-bus 1:

• 100kHz - Actual = 62.5kHz

• 600kHz - Actual = 375kHz

The '100' and '600' are changed values in /boot/config.txt, for example:

• dtparam=i2c_baudrate=100000

• dtparam=i2c_baudrate=600000

What happens if you measure the frequency after increasing CPU load? Run cat /dev/urandom > /dev/null & to make some fake load.

jdb wrote:What happens if you measure the frequency after increasing CPU load? Run cat /dev/urandom > /dev/null & to make some fake load.

Interesting...I have my 'dtparam=i2c_baudrate=600000' set up in the /boot/config.txt, as previously posted. If I run the normal 'i2cdetect -y 1' (without your suggestion), I get 375kHz (as previously mentioned). If I run your command and then do an i2cdetect, it is exactly 600kHz, as I set up in the dtparam. Good suggestion! Other than loading the CPU, is there another remedy?

I also checked on the same board with a Compute Module 1 - it does not have these i2c differences...dtparam=i2c_baudrate=XXXXXX sets the frequency exactly to XXX,XXXHz, as one would expect. It is not experiencing the same I2C differences that the CM3 is.

Thanks in advance!

The I2C block divides the system clock which is variable. With no loading, the core clock frequency is 250MHz and when there is activity, it increases to 400MHz.

Ideally, the clock driver(s) should all talk to each other and notify before/after a clock change event so that dividers can be recalculated seamlessly. A workaround is to have an explicit core_freq=250 in /boot/config.txt, but certain high-bandwidth GPU operations may be constrained by restricting the core clock (advanced deinterlace, H265 decode).