Teensy 3.2 , and I2C

Status
Not open for further replies.

drjohnsmith

Well-known member
I'm fishing here ....

Have a few teensys here, running,
using them to interface to I2C chips / things.

So I know about capacitance, rise / fall times, signal integrity, I2C speed,

But have a problem,

I increase the cable capacitance, and the I2C fails.
But when I look with nice fast scope,
I can see that the teensy is receiving what is still within in the old philips I2C rise / fall spec,

The I2C is failing when I hit around 200 ns rise time due to the pull ups.
I've looked at the timings of the pulses, and all looks well within the I2C spec,

I'm using t3_i2c for the wire library , but seem to have similar results with the standard wire library.


I've got some way to go on this ,
yes look at pull ups, check for glitches on the data / clock lines, may be I2C re generator,


but the signal just does not look half a sick as I2C I have seen working,

was wondering,

how I2C compliment is the I2C library ?

As I said, it works fine over short cables,
but was wondering about things like I2C glitch filters, does the cpu have them and are they turned on by default ?
does the teensey cope with the slow edge, wonder if the teensy is multiple triggering by the slow edge,




Don't know, and a long way to go , but as I know nought about the teensy code I thought I'd give a quick ask in case some one goes ah yes..


Thanks
 
I a quick ask in case some one goes ah yes..

Ah, nope.

And indeed a good number of people have used the I2C port over lengthy wires. Probably have been reported trying to run faster than 200 kbit/sec, but then that's pretty much expected when you have a long cable with a lot of extra capacitance.

Any chance you could try to reproduce this problem with the regular Wire library and fixed value capacitors? Think in terms of a reproducible circuit I would connect here on a solderless breadboard.
 
Thanks Paul

thats what I thought, I have run the teensy over long cable I2C before, just this client has to wire using VERY thin cable,
which is high capacitance,

It could be 1001 things, from the cable to the chips at the other end, to the connectors,
it was just strange enough that I wondered if the glitch detector was turned on , or could be turned on on the I2C on the teensy,
should help if there is any meta-stability problems on the IO pins of the I2C.
 
In case of high bus capacitance my suggestion would be to use an I2C bus buffer. I've had excellent results with the PCA9600. I've run it at 600KHz over 14 feet of CAT5 cable without problems and with the signal still looking crisp, so there's some headroom.

This was with 11 I2C devices on the bus. For point to point connections that distance can be much longer. There is a very good application note available online from NXP how to set that up.
 
Last edited:
In case of high bus capacitance my suggestion would be to use an I2C bus buffer. I've had excellent results with the PCA9600. I've run it at 600KHz over 14 feet of CAT5 cable without problems and with the signal still looking crisp, so there's some headroom.

This was with 11 I2C devices on the bus. For point to point connections that distance can be much longer. There is a very good application note available online from NXP how to set that up.

Thanks Headroom,

yes an I2C buffer is one of the routes we've looked at,

its just that the signal does not look too bad, certainly within I2C specification for rise time ( just ) and I have seen a lot worse .

could be 1001 things, was wondering particularly at the teensy end on the glitch filtering on the I2C and is it turned on , and can it be changed.

If any one knows how to talk to the teensy 3.2 internal registers, in particular the I2C glitch filters, that would be good info please.
 
Here's a link to the tips-&-tricks thread. I believe that also includes a link to the microcontroller spec sheet.

What value pull-up are you using on what length of what sort of wire ?
Are you running the bus at 3.3V or at 5V ?
What environment are you running this in ?

This application note AN10658 is worthy reading even if you decide to live without a I2C bus extender.

Also, my suggestion for a robust design would be to fix electrical/signal problems which these certainly are and only use software "tricks" as a last resort.
 
Here's a link to the tips-&-tricks thread. I believe that also includes a link to the microcontroller spec sheet.

What value pull-up are you using on what length of what sort of wire ?
Are you running the bus at 3.3V or at 5V ?
What environment are you running this in ?

This application note AN10658 is worthy reading even if you decide to live without a I2C bus extender.

Also, my suggestion for a robust design would be to fix electrical/signal problems which these certainly are and only use software "tricks" as a last resort.

Thanks Headroom,

I'd missed that app note, but its now on my usb stick of "good stuff" , just in case.

All good points about the cable length, pull ups, etc, were looking into all those, and quiet a few more..

it was the teensy 3.2 , and the I2C glitch remover circuit of the Teensy I2C pins in the chip I have no knowledge on,
was wondering how to control that and were they set up already, if so what to.

In theory , if the glitch filter is not set up, once I know how to control the registers in the chip, we could add it to the t3_i2c library as a parameter,
 
I'll put this to bed a little.

Well had a fun time with this, got the clients bits working, debugged intermittent broken cables , dry joints on pull up resistor, et all... but client now happy.

I'd still like to get to be able to set the glitch filters on the teensy 3.2 I2C pins, some sort of call to the registers,

from the looks of it , 'all' we have to do is program the I2C Programmable Input Glitch Filter register (I2Cx_FLT) to a number between 0 and 1F,
but don't know how to access that register.

may be one day.
 
Status
Not open for further replies.
Back
Top