Go Down

Topic: DUE i2c not stable (Read 7641 times) previous topic - next topic

davidreeves20

First, I'm certainly not a hardware guy so I probably have this all wrong ...and I probably have some of this confused with one wire(ds18b20s) which I've also been working with also... but I'm willing to put it out there in hopes that somebody will correct my misunderstandings.

My understanding of I2C is that the pullup resistor values impact how fast the signals or voltage on the lines (SDA and SCL) returns to "on" and how fast the value can be pulled to "off".  The required resistance needed varies with the voltage (5v or 3.3v) and with the length of the bus and what other devices are attached.  My biggest issues were resolved by no longer using breadboards and jumper wires!  I think some i2c devices also have built in pullup resistors.  I have been trying to minimize the length of the connections to the other i2c devices and from other's suggestions came to try 2k2 with 3.3v with the DUE and have used 4k7 with 5v ok...but I only KNOW what has worked for me and what shows up with the i2cscanner and i2cmultispeedscanner code.  I don't have access to a scope at the moment so I haven't been able to look at the operation of the lines to see if they are showing a good digital signal or if it is really marginal with these resistor values.  I THINK that with a scope on the SDA and SCL lines you should see whether the voltage was returning to the correct "on" voltage quickly enough and whether it was reaching the correct "off" value sufficiently to work reliably.

I'm sure someone else could better explain how a higher or lower resistance will affect the signal.

As for 10k...my understanding is that most people have better luck with 4k7 additional pullup resistors with the UNO and 5v i2c...because the UNO also has built in pullups and I did try them with the UNO and DUE but they didn't work well for me and after reading more there seemed to be more success with 2k2 with the DUE and I got my application to work with that.  I've been more trial and error but I think that with a scope you could eliminate the guess work.

The pullup resistors are supposed to be connected between each SDA/SCL and Vcc not ground.

I was talking about putting a scope on the SDA and SCL lines with the i2c devices during (attempted) operation.

MrAl

Hello again David,

I do happen to be a hardware guy :-)
So i took your advice and looked into the hardware aspect a little more.

You are right that a scope would help here as then we could look at the rise and fall times and see that they are adequate.  You may want to note however that would still not be a blanket solution, but rather would have to be performed on a per-application basis.
Part of the reason for that is the type of transmission line (jumpers, traces, etc.) and part is due to the total capacitance of the line and device being operated.
For example, with 100pf 10k might be ok, but with 200pf 5k would be more like it, and with 300 to 400pf 2.5k would have to be used.
Interestingly, there is a min too, not just a max like that.  The min is about 1k for a 3.3v pin and about 1.8k for a 5v pin.  This i think is so that the pin is not stressed too much.  If we draw more current than allowed out of the pin we risk early failure.

There is more to read in the specification if anyone cares to look at that too, but that's the basic idea.
So looking at it with the scope might help one application but not the other because the capacitance is different, so each application unless exactly the same as the other would have to be scope'd individually.
It couldnt hurt though to test using a standard LCD like the 1602 just to see what it looks like.  The rise and fall times would have to be gleaned from the specification for IC2 which notes those values.

A workaround, not having a scope, could be done like other workarounds in analog design.  That is, start with 10k, and if that doesnt work, go down to 5k, and if that doesnt work go down to 2.5k, etc., until reaching the min of course.
If we obtain success with 5k, then go up to 7k, and if still successful we know that 5k is probably good. If not successful, then go down to 6k.  If that still doesnt work then we might be marginal with 5k, so go down to 4k and that is probably good because we already know that 5k works.
So the idea is to test with several values, and find the value that is lower than the last value that is found to work by say 20 to 25 percent.
It also goes the other way too, if we find that 2k doesnt work but 2.5k works, then we might try to find the upper limit as well then choose the value right between the two values.  So if 2k doesnt work but 2.2k works, and 4k also works but 4.2k works, then half way between 2k and 4k is 3k so that would be the best choice.  If it turns out that all values down to 1.5k works, then we could go with a value 25 percent less than the highest value that works, or maybe even a little lower.
So it becomes trial and error but in a very ordered manner.

naga_jyothi

Hi David,

Even I am planning to use two I2C ports in Due board.

But I am able to get only one senor I2C data at a time and not stable.

Can you suggest some example code with schematics

scanfff

I have a rtc module hooked to SCL/SDA which works great.  I Just got a temp. sensor which runs perfect on the mega.  It will not work on the Due, actually I tried two different Due boards.  

The I2C looks like a big issue on the DUE.  Is there an I2C software library available that anyone knows of.  

dougcl

#19
May 11, 2017, 11:34 am Last Edit: May 12, 2017, 02:32 pm by dougcl
I have a rtc module hooked to SCL/SDA which works great.  I Just got a temp. sensor which runs perfect on the mega.  It will not work on the Due, actually I tried two different Due boards. 

The I2C looks like a big issue on the DUE.  Is there an I2C software library available that anyone knows of. 
It appears that the AVRs have 50ns glitch filters and falling edge slew limiters built into the TWI hardware.

From the Atmega 1280 datasheet:
Quote
24.5.1 SCL and SDA Pins
These pins interface the AVR TWI with the rest of the MCU system. The output drivers contain a slew-rate limiter in
order to conform to the TWI specification. The input stages contain a spike suppression unit removing spikes
shorter than 50ns.
The ARMs have nothing. So if you have a long I2C bus, you have ringing on the falling edges, and the clocks coming into your board will have glitches on the order of 50ns, and your clocks leaving your board will generate these glitches as well. This leads to double clock counts and devices falling out of sync, pulling SDA low to ACK at the wrong times, eventually colliding with another device trying to let SDA go high and the bus will lock up with SDA held low. Seems the AVR was specifically designed to cover this, whereas the ARM was not.

Meanwhile, I have had great success running I2C using the Wire library on a SAM3 at even 400kHz on a short I2C layout. No problems whatsoever. There is nothing wrong with the TWI library (v1.5.8 anyway) and nothing wrong with the Due.

If you have long I2C wires, and are not planning on interfacing more than one Due to your I2C bus, add a 200pF cap to ground on both SDA and SCL. This will take care of the glitches coming into your Due. Also consider 10 or 20 ohm series resistors between the Due and the bus. This will attenuate the glitches leaving your Due.

Doug

ard_newbie


PIO Controller Input Filter Enable Register (PIO_IFER) enables the input glitch filter on a selected I/O line for glitches with a duration  < 23.8 ns. It should help but not resolve the entire issue.

dougcl

PIO Controller Input Filter Enable Register (PIO_IFER) enables the input glitch filter on a selected I/O line for glitches with a duration  < 23.8 ns. It should help but not resolve the entire issue.
Datasheet says that glitch filter settings in PIO have no affect on peripherals (TWI is a peripheral):

Quote
When the glitch and/or debouncing filter is enabled, it does not modify the behavior of the inputs on the
peripherals. It acts only on the value read in PIO_PDSR and on the input change interrupt detection.
The TWI section explicitly states that input filtering and slope control are not supported (table 33-1).

Doug

ard_newbie


You are right :) . I discovered that input filtering is supported in Sam7 thru TWIHS_FILTR register.

dougcl

#23
May 12, 2017, 03:37 pm Last Edit: May 17, 2017, 04:48 am by dougcl
You are right :) . I discovered that input filtering is supported in Sam7 thru TWIHS_FILTR register.
Good to know :)

It appears that the SAMD21 (Arduino Zero) also has filtered inputs and slew limited outputs.

Go Up