Wire clock is slow for some 3.3V devices.

[greiman]

The RA4M1 I2C controller runs slower than the selected clock rate for some 3.3V devices. These devices run at the full rate on Uno R3.

I have had no problems with 5V devices. All 5V devices I have tried run at 400kHz.

I looked for any issues for RA4M1 on the Renesas site. It seems the controller is very fussy for 3.3V devices. Devices fail if powered by slightly less than 3.3V and Renesas states:

For the functioning of IIC Slave on all the boards except for EK-RA6M3/EK-RA6M3G,FPB-RA6E1,external pull up resistors of value 3.9 or 4.7k ohms are required to be connected on I2C(SDA/SCL) lines.

Here is an example with a SSD1306 128 x 64 OLED display which has 4.7 K pullups to 3.3V.

On a R4 Minima I get 329kHz for 400kHz requested clock. I get 95kHz for 100 kHz requested clock.

I added an analog trace for SCL.

For the same program and device on Uno R3 I get exactly 400 kHz.:

Any Ideas what is causing 3.3V devices to run a bit slower on R4?

I have not tried more than one I2C device at a time on R4.

Edit: Are internal pullups enabled on R4?

[mjs513]

@greiman
Did you see my comment to wire.setClock PR: #46 (comment) and link to Forum post on that topic.

[greiman]

@mjs513

I am not sure what the fix is. 5V devices run at slightly over 400kHz, 3.3V have some rate less than 400kHz. It appears to vary a lot depending on the device.

I have not experimented with mixes of devices.

I2C has clock stretching. Maybe at close to 3V the Renesas controller thinks the device wants to slow down.

From the standard:

Clock stretching pauses a transaction by holding the SCL line LOW. The transaction
cannot continue until the line is released HIGH again. Clock stretching is optional and in
fact, most target devices do not include an SCL driver so they are unable to stretch the
clock.

The other problem with Wire is that you can't select a rates other than 100kHz, 400kHz, 1MHz. setClock just ignores other rates.
See this.

Seems like Renesas should help with this.

[greiman]

@mjs513

Thanks for your post. I decided to play with pullup resistor size and pullup voltage.

Case with bigger resistor. Rate goes from above 325 kHz to 285 kHz.

Case with even larger pullup resistor (larger resistor means less pullup). Clock becomes erratic. The device still works!

At about 3.0 V pullup voltage, the clock stops for any pullup resistor size.

[greiman]

Adding a 5V device makes the 3.3V device go faster. The 5V pullup causes the clock to have higher peak voltage.

[paulvha]

Just out of interest.. did you connect to the Qwiic connector (Wire1) or to the A4/A5, D18/D19 (Wire).

The reason for asking is that the Qwiic connector (Wire1) is 3V3. The SCL/SDA signals get a level change from 3V3 to 5V and are then connected to the Renesas processor.

[greiman]

@paulvha

Just out of interest.. did you connect to the Qwiic connector

I did not use Wire1 on the Qwiic connector.

I think there is a good chance a level shifter would help.

I was looking at the I2C standard and was realizing we have been lucky with the forgiving nature of the Uno R3 and other I2C controllers.

If VDD is the bus voltage, that is the pullup voltage then:

VL, Max LOW-level input voltage. is 0.3*VDD, or 1.5 V if VDD = 5V.

VH, Min HIGH-level input voltage is 0.7* VDD or 3.5 V if VDD = 5V.

So for a 3.3V, the bus max voltage is less than the 3.5 V specified by the standard for min HIGH voltage.

I have made devices work by adding pullups to 5V. I suspect most devices are 5V tolerant. Since:

The output stages of devices connected to the bus must have an open-drain or open-collector to perform the wired-AND function.

The standard says things like this:

This bridge includes a level shift function that allows devices with different supply voltages to be connected.

I have Qwiic connectors/cables and devices but I wish someone else would pursue this issue.

[mjs513]

@greiman
Sorry I didn't get back sooner been a crazy morning. I was trying to duplicate your results with a mix of 5v and 3.3v devices on the same bus.

Right now I am testing with a Lidar Lite V3 (5v), SSD1306 and a 3.3v MPU9250. This is all running the Wire from a Minima board.

If hook up a LA and look at each device in the traces:
9250 (0x68) - alternates between 400khz at 52% and 384khz at 53.8% duty.

0x62 (Lidar Lite V3) - same thing, alternates between 400khz at 52% and 384khz at 53.8% duty.

0x3c (SSD1306) - same thing, alternates between 400khz at 52% and 384khz at 53.8% duty.

Individually I am seeing what you saw. The only PRs that I have incorporated were micros, and the setclock fixes.

[greiman]

Just out of interest.. did you connect to the Qwiic connector

I did. Works like a charm with a SDD1306 display on Wire1.

I looked at many captures and it almost always runs at 399.04 kHz. A tiny variation but that is within sampling error for the logic analyzer.

The voltage on the Qwicc connector is 3.29 V. The display is powered by this voltage.

[paulvha]

Great work mjs513 and greiman. I think your investigations made it clear and Arduino should document the different references. On the R4 the Wire() should be used for 5V devices and thus backward compatibility with R3, Qwiic/STEMMA (Wire1) should be used for 3V3 devices.

[greiman]

@paulvha

I agree. Too bad the R4 Minima has only the 5V Wire.

The Uno R3 works well with 3V3 I2c since at the time the AVR I2C controller was designed there were many legacy devices.

Here is a statement from the I2C standard:

Some legacy device input levels were fixed at VIL = 1.5 V and VIH = 3.0 V, but all new devices require this 30 %/70 % specification.

So now the minimum voltage for HIGH on 5V devices is 70% of 5V or 3.5V.

[mjs513]

@greiman = been testing a bit more today with a I2C test board that we used with the Teensy, same as previously but with more added:

#define _MPU9250_port Wire1
//#define _BNO055_port  Wire2  
#define _BNO080_port  Wire2
#define _LIDAR_port   Wire
#define _MB85_port    Wire1

Note an SSD1306 is on Wire

In that configuration the test sketch worked fine no issues but the minute I enable the BNO055 it indicated it could not be found. I enabled the 055 and disabled the 080 it worked.

Earlier in the morning was testing with a bno080 + a TPM102 board on Wire + a 9250 on Wire1 and after a few seconds the sketch lost the all devices on Wire but wire1 kept working.

Have to do some more testing but it might be an issue with these BNO type devices.

Just thought you would like to know.

[mjs513]

Did some more testing with the BNO055 and TMP102 devices on Wire/Wire1. Confirmed they fail on both ports. Tested on a M0 board that I have and no issue. Did verify that wirescanner picked them up and they did.

[paulvha]

don't know about the TMP102, but the BNO0555 is using clock stretching and caused many issues with the RPI. There are many articles on internet.. Could that be a reason ?

[paulvha]

The BNO080 also suffers with clock stretch.. e.g. adafruit/Adafruit_CircuitPython_BNO08x#7

[mjs513]

@paulvha - Actually I think I got it resolved. Out of curiosity I looked at another library for the BNO55 for the arduino: https://github.com/arduino-libraries/BNO055, and saw this//Pin assignments as tested on the Arduino Due.

//Vdd,Vddio : 3.3V
//GND : GND
//SDA/SCL : SDA/SCL
//PSO/PS1 : GND/GND (I2C mode) setup in the example

Never hooked up PS0 and PS1 to gnd before so gave it a try and it worked. So now have data streaming from both the 080 on Wire1 and 055 on Wire.

Also works with both devices on Wire :) Wonder if there is some delta in the libraries for the 2 chips since both have PS0/PS1 lines