I2C 1MHz spikes, Software Serial, capacitance, pullups and other problems...

Hi everyone,

Well well, where to begin…

I am using several Arduinos networked via I2C (and Serial, I’ll get to it) to eventually transmit all the datas to the PC via RS232 to log a series of comma separated printed values.

… and of course nothing is working as it should!

So first in line : the I2C was acting up but my cable was around 600pF so out of spec for I2C, I replaced it with 2meters of CAT5 cable and it was ok.

But this solved, time for the real problems :

  • For some reasons, the communication between the Arduino reading the thermocouple values and transmitting on I2C request and the “main” / logging arduino doesn’t work. The main only reads bytes @255 (except for the first byte which does return the internal T° value).
  • The RS232 to the Arduino MEGA is quite unstable and erratically returns values of 128, I guess this has to do with it being software serial but then again the UNO only has one hardware RS232…
  • Conequently, I have to set the polling of the ADC to only once every 500mS or otherwise the RS232 from the mega doesn’t work. I guess it’s also related to it being bit-banging but I’d like a confirmation if possible…
  • And on a more hardware level, when I scoped my I2C bus (WITH the 600pF cable!) the rising edges were nice and quick (go figure…) but I had also 1MHz spikes in between the clock tops… What the hell is that!!!
    I’m using freqmeasure library which (I guess) is using a timer, would it have anything to do with it?

Attached is a printscreen of the scope reading.

Also a very badly done schematic of the general architecture and the sketches from the Main Arduino & The TK multiplexer.

Thanks for your help everyone!

ArduinoSketches.zip (6.5 KB)

Anyone encountered the same type of problems with software serial for example?

Pretty please? :smiley:

Does the I2C look better with more samples/second? I think you're just scope seeing limitations, perhaps mixed with long ground wire on the scope.

I2C is its own set of hardware, software serial shouldn't affect it.

If you need 2 hardware serial ports, consider going to a '1284P based design.

And on a more hardware level, when I scoped my I2C bus (WITH the 600pF cable!) the rising edges were nice and quick (go figure...) but I had also 1MHz spikes in between the clock tops... What the hell is that??!!

Haven't used I2C yet, but the spikes have a definite pattern.
It consistantly matches a serial 8N1 configuration (start bit LOW, data bits 0-7 HIGH, stop bit HIGH):

@Crossroads :

I haven’t seen it change with more sample/s but I’m not sure what you mean…

@dlloyd

I’m scoping the clock line so I doubt there’s any logic to be extracted of…

I'm scoping the clock line so I doubt there's any logic to be extracted of...

Well, it consistently follows the 8N1 with data 0XFF pattern. Notice how 2 bytes fit exactly between the clock HIGH pulses. Stretching out the pattern will give a better picture, but it would have poor rise/fall time at that frequency combined with the capacitance of the probe. It's not really a question of extracting usable logic, just need to determine the cause.

Some questions to consider ...
Could there be more than one device using the same I/O pin as the clock?
What code is being executed between each clock pulse?
Could an adjacent I/O line be influencing this signal?

To determine what it is, I would selectively disable individual devices, or section(s) of code, especially anything pertaining to serial communication (SPI, I2C, RS232, USB, etc). When the problem disappears, then you'll know or be much closer to determining the true cause.

Hi Dlloyd,

I’ll try stripping the sketch one by one, it is indeed the only way to know where it’s going wrong…

In the meantime I’ve observed a behaviour that I don’t understand.

I’m trying to debug the I2C to the Arduino UNO with the multiplexer shield but can’t make any sense out of it…

So I’m in the master reader, slave sender configuration and I have this code on the slave (onRequest) :

void I2Csend()
{    
  int p=591;

  Wire.write(byte(T[8]));
  Serial.println(byte(T[8]));

  byte  x=lowByte(p);
  Wire.write(x);
  Serial.println(x);

  byte y=highByte(p);
  Wire.write(y);
  Serial.println(y);

  Wire.write(byte(7));
  Serial.println(byte(7));

}

And if I look at the console, I do get : 24, 79, 2, 7 (by heart).

And this code on the master reader (that I trigger every 150mS) :

void I2C()     

{

  if(millis()>TKperiod)
  {
    TKperiod=millis()+150;

    Wire.requestFrom(0x47, 4);
  
  while(Wire.available()>0)
  {
    T[8]=Wire.read();
    h=Wire.read();
    l=Wire.read();
    m=Wire.read();
    T[m]=word(h,l);
  }
   
}

While the I2C on the slave gets requested (since I get the serial.print in the console and they show the right figures), on the Master I get these :

7 255 255 255 0

which is in order : T[8], h, l, m, T[m]

So first of all, it seems the I2C buffer is LIFO and not FIFO (anyone can confirm me on that?).

But also, I really don’t understand why only the 7 gets transmitted and none of the others…???

Thanks for your help!

Marc

Oh and also...

The rest of the I2C communication to the 2x ADS1115 ADCs is working perfectly fine so even more mystery...

Another thing to check would be that each device has a unique address (I think there's example code somewhere that will list addresses found). Need to be sure that only one device is in control of the bus at a time.

Can't help much further as I haven't used I2C yet on an Arduino.

Hi Dlloyd,

Well as far as I know, they all have a unique adress.

Main Arduino (that's requesting the I2C) doesn't have an adress
ADC1 : 0x48
ADC2 : 0x49
Arduino Thermocouple MUX : 0x47

Well that's all I know for now...