Could you let us know how you measured those signals? Could you also add pictures of all measurements?
thanks for the interest. The methodology I used to acquire the measurements is the following:
1. I configure the I2C controller (nr. 6) on fast mode through the /sys interface
2. I run a C program that opens the i2c device-file with a given slave address - the slave address does not correspond to any device on the bus
3. I run a while-loop with a read operation on the device-file. Since no device answers on the bus, I get no data back, but that allows me to observe how the read request has been formed by the I2C controller on the bus using an oscilloscope.
4. I probe pins corresponding to GPIO 27 and GPIO 28 (I2C controller nr.6)
5. I measure the peak-to-peak duration and hence the frequency of the SCL signal.
The picture above shows the behavior of the controller sending the address byte in "fast" configuration. The address (0x19) is correctly sent (0011001b), followed by a read bit (1b) and a NACK bit (since no device is answering). The clock speed outputted by the oscilloscope is 383 kHz. It can also be calculated using the timing between marker "a" and "b"
The picture above show the signals for the address byte generated by the controller in "high speed" mode. There are several problems with this signal. First, the clock is too low (again ~380 kHz) and it seems unstable toward the end of the byte. Moreover, the address byte now reads as: 000010011b = 0x04 (address - not what I sent) + read + NACK.
Hope it helps! Thanks again for your time.
hold on. I did a quick search for the high speed mode. Seems that what we see on the scope may be fine: http://www.i2c-bus.org/highspeed/
The transmission starts in fast speed mode and from the second byte on continues in high speed. Moreover, in high speed mode the first byte is a constant code: 0001XXX+NACK.
Next, the slave address is transmitted. It is hard to see from the figure if in this case the address byte is being formed correctly, but at least the signal may not be totally wrong. I need to test an actual communication with a high-speed capable device.
BTW: the clock speed in high-speed mode seems 833 kHz, which is far from the 3.4 MHz maximum, but may be ok.
I believe you are right, this might be the expected behavior from an I2C device connected to air. I believe you might find different results if you connect a device to it. Try to connect an I2C device to the board and try sending data to it, when doing so, measure it with the oscilloscope but also measure the clock signal so we can compare the timing to what we should expect. Also, remember to use pull-up resistors and that everything is connected properly, believe it or not those are the main reasons for I2C issues .