vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

I2C device responding on all addresses

Fri Dec 28, 2012 7:00 am

Folks, I have a RasPi V2 here (512mb) which is doing some strange things with I2C.

I have had issues with I2C on my BeagleBone board, so I've moved to the RasPi as it's interface is a bit simpler (no pin muxing particularl) to try and get this hardware working first. All this I2C gear worked flawlessly on Arduino. (I think I actually hurt the BeagleBone by trying the LCD display with it at 5v when it only wanted 3.3v...)

First devices I've been trying are two Akafugu 7 segment displays (seperately): http://www.akafugu.jp/posts/products/twidisplay/

It works with 3.3v and 5v, for now I've connected it with 3.3v so I don't have to bother with level converters etc. I have enabled the i2c-dev and i2c-bcm2708 kernel modules, and rebooted. I see the i2c devices in the /sys directory etc, so no issues there as far as I know.

I have also tried with my 40x4 LCD display (works with Arduino) http://www.akafugu.jp/posts/products/twilcd/ which is 5v only. I connected it via a logic converter with 3.3v on the low side and 5v on the high side. This display was also not detected correctly

The specific issue that's occurring is that when I run the i2cdetect command with a device connected it appears to respond on every address most of the time, and nearly every address the rest of the time:

Code: Select all

[email protected]:/home/pi# i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77                         
[email protected]:/home/pi# i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77 
I'm running the latest Rasbian image, with the last apt-get update && apt-get upgrade done today, with a reboot to follow for good measure. No kernel related updates in this upgrade.

Code: Select all

[email protected]:/home/pi# cat /etc/debian_version 
7.0
[email protected]:/home/pi# uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
The connections look like this:
Image
RasPi I2C by auvortex, on Flickr

Image
RasPi I2C by auvortex, on Flickr

I haven't been able to try another ribbon cable, I made this one today but I will make another tomorrow to try and resolve the problem; it's possible this one didn't crimp correctly (pin 1 is in the correct location).

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 7:55 am

I forgot to mention, I verified all the pins were in the right places with a multimeter, so I'm sure the correct connections are made.

I have just swapped in my older V1 RasPi and the same behaviour occurs.
Reversed the ribbon cable, plugged all pins back in the correct locations, same behaviour.

Does anyone have any thoughts on this? Kernel issue? I assume I2C is working for many others..?

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 1:03 pm

Further developments with this. I have connected my Freetronics Relay8 (which is actually an Arduino shield!) and it's detected with I2C correctly via logic convertor.

All my other LCD's (the 7seg and the 40x4 (backpack specifically)) are Akafugu devices, and none of them work on RasPi or BeagleBone. It appears to be something consistant with their firmware or devices. I'm going to connect the BeagleBone again and see if it works, too.

Super disappointed that all the Akafugu devices aren't working, though.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Fri Dec 28, 2012 3:08 pm

I suspect it has a pseudo I2C interface as it requires a 4k7 to 10k pullup on I2C lines, whilst Pi has 1k8 (much lower).

I suspect it does not have a proper I2C port on the diesplay and have seen some LCD with I2C have series resistors (internally) on these lines that cause all sorts of problems.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 8:51 pm

I have some 4.7k ohm pull up resistors here, how would I connect them into the circuit to make those devices work?

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 11836
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: I2C device responding on all addresses

Fri Dec 28, 2012 9:07 pm

To make pullup stronger, simply connect a second resistor between the I2C lines and 3,3 Volt.

If an I2C device has problems with 3,3V high levels try if lowering its VCC voltage level a little bit.

If this doesn´t help try adding level shifters in the I2C lines. Level shifters consist of an NFET and an extra pullup. google for I2C levels shifter for more info (specifically a Philips white paper) .

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 9:13 pm

ok, so the SDA and SCL lines will each have a resistor connected to 3v3?
I have used one of the LCDs with a level converter (logic converter, is there a difference?) and there was no difference.

Akafugu tell me they have tested these boards and they work OK..

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 9:44 pm

I've connected one of the 4k7 pull up resistors from SDA to the 3v3 supply, and another 4k7 pull up from the SCL line to the 3v3 supply. Is this correct? They are on the low side of the logic converter if that matters.
The same behaviour occurs when trying to scan the i2c bus, so no luck.

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 11:24 pm

Trying with a 3v3 LCD with no logic converter, no combination of pullup resistors is making it work.

The other device I had working is flaky, it only works for a few minutes and then it disappears again.

Not having much luck with this.

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Fri Dec 28, 2012 11:25 pm

mahjongg wrote:If an I2C device has problems with 3,3V high levels try if lowering its VCC voltage level a little bit.
I don't think this is the problem as it works at 5v on Arduino; but so I can try that, how would I do it?

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Fri Dec 28, 2012 11:42 pm

First checks when wired on Pi (I suspect an oscilloscope would show the problems quicker)

With power off measure Impedance/resistance between
  • SDA and GND
  • SCL and GND
  • SDA and SCL
As they recommended a 4k7 to 10k pullup, adding more in parallel with 1k8 on Pi will probably make problem worse.

With power on check i2cdetect with GPIO cable disconnected then connected.

You may need to put an I2C repeater in, which works differently to a level translater a PCA9515A or PCA9517A and have 10k pullups on display side for both SDA and SCL to 5V.

I would not recommend operating the LED display on 3V3 as the LED display will draw a fair bit of current, unless you have another source of 3V3 other than the 3V3 pin on the Pi GPIO connector.

I personally suspect either a short SDA to GND or bad I2C port spec on the display.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Sat Dec 29, 2012 12:21 am

The problem exists across multiple devices, i have two of the 3v3 7segment lcds and they both do the same thing.

When i pull one of the pins, i2cdetect returns nothing.

I dont have access to an oscilloscope. Hell i dont even know how to use most of a multimeter :)

Ill look up how to make those checks with the multimeter i have and report back.

Why is this so much harder than on arduino?

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:16 am

Ok, at home with the multimeter now.
I'm not sure what resistance setting I should use, so i've found one that shows 'something'. Weather it's correct, someone will need to tell me :)

I picked 200k on the multimeter, and I see a '1 . ' on the display.

When I put the Positive on SDA, and Negative on Negative, it says: '1 . ' IE, no change.
When I pit the Positive on SDA, and Negative on SCL, it says: '0.36'. On 20k it says '3.6' so just shifted the decimal place.
When I remove the ribbon cable and measure directly on the pins, this reading is the same.
When I put the Positive on SCL and Negative on Negative, it says '1 . ' IE no change.

So, where does that leave me?

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:26 am

Means no shorts, values as expected for good setup.

What I2C clock speed do you use for the displays on Beagleboard and Arduino?

If 100kHz or lower, then would suggest display cannot work at 400kHz of Pi.
If 400kHz we need to find another solution possibly I2C repeater.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:28 am

techpaul wrote:Means no shorts, values as expected for good setup.

What I2C clock speed do you use for the displays on Beagleboard and Arduino?

If 100kHz or lower, then would suggest display cannot work at 400kHz of Pi.
If 400kHz we need to find another solution possibly I2C repeater.
No idea sorry. How would I check that?

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:30 am

The spec of the Arduino and beagle board and how the software on those works for setup of clock speed for I2C.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 11836
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:40 am

okay, I still suspect a logic (high) level problem (logic low levels are almost never a problem, unless you have a bad grounding problem.
the problem exists because you are trying to connect both 3V3 and 5V powered devices using the I2C bus. Now one of the points of the I2C bus is that no I2C device will ever try to push its logic high level onto the bus! All I2C devices should be open collector (or open drain) devices, and the logic high signal should only be applied because of pullup resistors. And because 3V3 devices such as the PI are designed only to accept logic highs of no more than 3V3, the pullups should be connected to the lowest VCC voltage used by the devices, in this case 3V3. Anyway when you try to put more than 3V3 + one diode drop on the GPIO the voltage will be shorted to the PI's 3V3 supply through the diode that is integral to the N-FET that is used to drive a logic high out of the GPIO pin, that means the voltage on the I2C bus signals can never rise above 3,3V + 0.5V = 3,8V or so.
now if you look at the datasheet of many logic IC's you will see a Vih-min a minimum for an acceptable "logic high" voltage level for the device, many devices have a ViH-min that is 2.0 V, specifically so that the device is compatible with 3V3 logic. But older devices often specify ViH-min to be 60% of VCC, for a 5V powered device this means 3.0V which is very close to 3,3V, and means that noise or other disturbances may cause the device not to see the logic highs.

One solution is to lower the VCC of these devices, which may or may not be possible depending on the minimum voltage of VCC for the device, but for example if the device still works with a VCC of 4.5V then the ViH-min will be lowered to 0.6 x4.5 = 2,7V and that may be all it takes to get it to recognize the available logic high signal.

a level shifter splits the I2C bus into two parts, one uses 3V3 levels and the other 5V levels.

If you use a multimeter I would use it to measure the logic high levels of the I2C bus.

by the way, the VCC of a device can be lowered by half a volt simply by putting a diode in-between the 5V supply and VCC of the device (obviously with decoupling capacitors on VCC)

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:44 am

Apparently they all support high clock speed of 400mhz, according to http://quick2wire.com/articles/i2c-and-spi/

The akafugu site doesn't say what speed the 7 segment display or the LCD backpack supports.

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:46 am

mahjongg wrote:okay, I still suspect a logic (high) level problem (logic low levels are almost never a problem, unless you have a bad grounding problem.
the problem exists because you are trying to connect both 3V3 and 5V powered devices using the I2C bus. Now one of the points of the I2C bus is that no I2C device will ever try to push its logic high level onto the bus! All I2C devices should be open collector (or open drain) devices, and the logic high signal should only be applied because of pullup resistors. And because 3V3 devices such as the PI are designed only to accept logic highs of no more than 3V3, the pullups should be connected to the lowest VCC voltage used by the devices, in this case 3V3. Anyway when you try to put more than 3V3 + one diode drop on the GPIO the voltage will be shorted to the PI's 3V3 supply through the diode that is integral to the N-FET that is used to drive a logic high out of the GPIO pin, that means the voltage on the I2C bus signals can never rise above 3,3V + 0.5V = 3,8V or so.
now if you look at the datasheet of many logic IC's you will see a Vih-min a minimum for an acceptable "logic high" voltage level for the device, many devices have a ViH-min that is 2.0 V, specifically so that the device is compatible with 3V3 logic. But older devices often specify ViH-min to be 60% of VCC, for a 5V powered device this means 3.0V which is very close to 3,3V, and means that noise or other disturbances may cause the device not to see the logic highs.

One solution is to lower the VCC of these devices, which may or may not be possible depending on the minimum voltage of VCC for the device, but for example if the device still works with a VCC of 4.5V then the ViH-min will be lowered to 0.6 x4.5 = 2,7V and that may be all it takes to get it to recognize the available logic high signal.

a level shifter splits the I2C bus into two parts, one uses 3V3 levels and the other 5V levels.

If you use a multimeter I would use it to measure the logic high levels of the I2C bus.

by the way, the VCC of a device can be lowered by half a volt simply by putting a diode in-between the 5V supply and VCC of the device (obviously with decoupling capacitors on VCC)
Thanks for the help, but everything you said is WAY over my head now. I realise that's my issue, but I can't help but think it should be a lot simpler than this.

I guess the Arduino (and the countless I2C with RasPi/BeagleBone sites) lulled me into a false sense of security that it 'just works'.

vortexau
Posts: 28
Joined: Fri Dec 28, 2012 6:11 am

Re: I2C device responding on all addresses

Sat Dec 29, 2012 2:27 am

techpaul wrote:What I2C clock speed do you use for the displays on Beagleboard and Arduino?

If 100kHz or lower, then would suggest display cannot work at 400kHz of Pi.
If 400kHz we need to find another solution possibly I2C repeater.
BeagleBone uses 100khz, as does Arduino. RasPi of course uses 100khz, too.

Code: Select all

[email protected]:/sys/class/i2c-dev/i2c-0/device# dmesg | grep i2c
[   12.734055] bcm2708_i2c bcm2708_i2c.0: BSC0 Controller at 0x20205000 (irq 79) (baudrate 100k)
[   12.931626] bcm2708_i2c bcm2708_i2c.1: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100k)
[   24.829892] i2c /dev entries driver

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Sat Dec 29, 2012 1:07 pm

vortexau wrote:
mahjongg wrote:okay, I still suspect a logic (high) level problem (logic low levels are almost never a problem, unless you have a bad grounding problem.
the problem exists because you are trying to connect both 3V3 and 5V powered devices using the I2C bus. Now one of the points of the I2C bus is that no I2C device will ever try to push its logic high level onto the bus! All I2C devices should be open collector (or open drain) devices, and the logic high signal should only be applied because of pullup resistors. And because 3V3 devices such as the PI are designed only to accept logic highs of no more than 3V3, the pullups should be connected to the lowest VCC voltage used by the devices, in this case 3V3. Anyway when you try to put more than 3V3 + one diode drop on the GPIO the voltage will be shorted to the PI's 3V3 supply through the diode that is integral to the N-FET that is used to drive a logic high out of the GPIO pin, that means the voltage on the I2C bus signals can never rise above 3,3V + 0.5V = 3,8V or so.
now if you look at the datasheet of many logic IC's you will see a Vih-min a minimum for an acceptable "logic high" voltage level for the device, many devices have a ViH-min that is 2.0 V, specifically so that the device is compatible with 3V3 logic. But older devices often specify ViH-min to be 60% of VCC, for a 5V powered device this means 3.0V which is very close to 3,3V, and means that noise or other disturbances may cause the device not to see the logic highs.

One solution is to lower the VCC of these devices, which may or may not be possible depending on the minimum voltage of VCC for the device, but for example if the device still works with a VCC of 4.5V then the ViH-min will be lowered to 0.6 x4.5 = 2,7V and that may be all it takes to get it to recognize the available logic high signal.

a level shifter splits the I2C bus into two parts, one uses 3V3 levels and the other 5V levels.

If you use a multimeter I would use it to measure the logic high levels of the I2C bus.

by the way, the VCC of a device can be lowered by half a volt simply by putting a diode in-between the 5V supply and VCC of the device (obviously with decoupling capacitors on VCC)
Thanks for the help, but everything you said is WAY over my head now. I realise that's my issue, but I can't help but think it should be a lot simpler than this.

I guess the Arduino (and the countless I2C with RasPi/BeagleBone sites) lulled me into a false sense of security that it 'just works'.
It should do but unfortunately some devices are not fully I2C compliant and quite a few assume they are the only device on I2C bus. The bus is meant for multiple devices to be connected quite often I have had to put in I2C repeaters to completely isolate certain devices often displays LCD or LED that do not have proper I2C interfaces. I have connected many I2C devices to the Pi and the only ones so far that have problems have been display devices.

I suspect you should try a level converter first with the display on a Pi, with a 10k resistor on SDA and SCL to 5V, but I have a stong suspicion that this device has a 'pseudo' I2C port because the port it uses on the onboard micro ATTiny4313 is multi function for many types of serial communication and is not a proper open-drain output and has some form of serial resistance and possibly high side driving.

To get this to work will probably need a I2C repeater like the PCA9515 or PCA9517 to work properly and then only when it has a 10k pullup on the display side.

A FET level does not completely isolate the 3V and 5V side as when either end is low it has a sum of the pullup currents from both sides flowing, which if you have some form of series resistance on a device (or its internal wiring), can really screw things up usually on LOW thresholds.

In your case you are seeing too many ACKnowledge pulses as being LOW at the Pi which suggest some strange issue on the display, which could only be really sorted by detailed analysis with a scope. It may also be worth trying to disconnect power to the display and once the Pi has started then put power on the display to ensure no funny sequence latch ups.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

akafugu
Posts: 2
Joined: Sat Dec 29, 2012 5:25 pm

Re: I2C device responding on all addresses

Sat Dec 29, 2012 5:35 pm

Hi,

I'm the designer of the boards in question, so I thought I'd chime in with some information.

I've connected both displays directly to the I2C on the RaspPI board (through a Adafruit
Prototyping Pi Plate) I just use the built-in pullups on the RaspPI. I have tested with
VCC connected to 5V (which works fine from the perspective of the slave device as 3.3V
is enough to trigger a high level), but it may be better to stick with 3.3V for VCC at
least for testing.

(TWIDisplay is fully 3.3V compatible: It will just work with lower brightness. For TWILCD
it depends on the actual dot matrix module connected)

When I run i2cdetect, only the correct addresses are reported as present and I can
communicate just fine (tested both using Python and C).

Both displays share the same i2c slave interface. It is software-based and runs on
an Attiny4313 with USI TWI slave firmware.

It is based on this appnote from atmel:
http://www.atmel.com/Images/doc2560.pdf

The device firmware is here:
https://github.com/akafugu/twidisplay/t ... mware-7seg
(relevant files are usiTwiSlave.c/.h)

The device is designed primarily for Arduino, and although I have used it successfully
with 400 kHz (on a netduino), it is probably a safer bet to stick to 100 kHz (not quite
sure how the speed is set on a RasPI though).

AFAIK the TWI Slave firmware uses the lines on the I2C bus properly (i.e. by toggling
the lines between input and output). It does pull SDA and SCL high on initialization,
could that be the problem?

There is no series resistor on the I2C lines, and I haven't had issues with having
it in series with several I2C devices.

I don't have access to my RasPI right now, but I will do some more testing here too
once I get the chance.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Sat Dec 29, 2012 6:23 pm

akafugu wrote:Hi,

I'm the designer of the boards in question, so I thought I'd chime in with some information.

I've connected both displays directly to the I2C on the RaspPI board (through a Adafruit
Prototyping Pi Plate) I just use the built-in pullups on the RaspPI. I have tested with
VCC connected to 5V (which works fine from the perspective of the slave device as 3.3V
is enough to trigger a high level), but it may be better to stick with 3.3V for VCC at
least for testing.

(TWIDisplay is fully 3.3V compatible: It will just work with lower brightness. For TWILCD
it depends on the actual dot matrix module connected),
The original poster claims to be use LED not LCD, running a 4 digit 7 segment (even multiplexed) LED from 3V3 available on Pi is questionable as not much 3V3 is available.
vortexau wrote:First devices I've been trying are two Akafugu 7 segment displays (seperately): http://www.akafugu.jp/posts/products/twidisplay/
akafugu wrote:When I run i2cdetect, only the correct addresses are reported as present and I can
communicate just fine (tested both using Python and C).
Wonder what happens with the LED version.
Both displays share the same i2c slave interface. It is software-based and runs on
an Attiny4313 with USI TWI slave firmware.

It is based on this appnote from atmel:
http://www.atmel.com/Images/doc2560.pdf

The device firmware is here:
https://github.com/akafugu/twidisplay/t ... mware-7seg
(relevant files are usiTwiSlave.c/.h)

The device is designed primarily for Arduino, and although I have used it successfully
with 400 kHz (on a netduino), it is probably a safer bet to stick to 100 kHz (not quite
sure how the speed is set on a RasPI though).

AFAIK the TWI Slave firmware uses the lines on the I2C bus properly (i.e. by toggling
the lines between input and output).
Proper I2C device has bidirectional pins with output in open drain mode, hence the pullup resistors.
It does pull SDA and SCL high on initialization, could that be the problem?
First problem I2C devices or even masters should NEVER pull output high that is what the pull up resistor is for. Second problem output should be configured as open drain for correct I2C see the NXP spec here http://www.nxp.com/documents/user_manual/UM10204.pdf

Any device that pulls output high means it cannot safely be used with any other device on the I2C bus, as another device could pull the output low and damage the driver.
There is no series resistor on the I2C lines, and I haven't had issues with having
it in series with several I2C devices.
More by luck than design in my personal opinion having been designing with I2C since about 1998, with many slave devices on I2C busses and some long cable lengths more than 10m.
I don't have access to my RasPI right now, but I will do some more testing here too once I get the chance.
Try the LED device as per his photos and the original post.

To original poster I would consider getting an I2C repeater and tieing its enable input to a GPIO pin, with a 10k pull down resistor, so you can have the device isolated and enable the I2C communication when you know device has powered up and initialised it might then stand a chance of working.

You could try a FET level shifter and drive the gate of the level shifter with a GPIO pin output with a 10k pull down to ground.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

akafugu
Posts: 2
Joined: Sat Dec 29, 2012 5:25 pm

Re: I2C device responding on all addresses

Sun Dec 30, 2012 5:14 am

techpaul wrote:
akafugu wrote:Hi,

I'm the designer of the boards in question, so I thought I'd chime in with some information.

I've connected both displays directly to the I2C on the RaspPI board (through a Adafruit
Prototyping Pi Plate) I just use the built-in pullups on the RaspPI. I have tested with
VCC connected to 5V (which works fine from the perspective of the slave device as 3.3V
is enough to trigger a high level), but it may be better to stick with 3.3V for VCC at
least for testing.

(TWIDisplay is fully 3.3V compatible: It will just work with lower brightness. For TWILCD
it depends on the actual dot matrix module connected),
The original poster claims to be use LED not LCD, running a 4 digit 7 segment (even multiplexed) LED from 3V3 available on Pi is questionable as not much 3V3 is available.
That is the reason I tried with 5V. To run at 3.3V an extra regulator is probably a good idea.

OP says he has been trying both devices with the same result in his first post.
techpaul wrote:
vortexau wrote:First devices I've been trying are two Akafugu 7 segment displays (seperately): http://www.akafugu.jp/posts/products/twidisplay/
akafugu wrote:When I run i2cdetect, only the correct addresses are reported as present and I can
communicate just fine (tested both using Python and C).
Wonder what happens with the LED version.
I get the same results on both types of display.
techpaul wrote:
Both displays share the same i2c slave interface. It is software-based and runs on
an Attiny4313 with USI TWI slave firmware.

It is based on this appnote from atmel:
http://www.atmel.com/Images/doc2560.pdf

The device firmware is here:
https://github.com/akafugu/twidisplay/t ... mware-7seg
(relevant files are usiTwiSlave.c/.h)

The device is designed primarily for Arduino, and although I have used it successfully
with 400 kHz (on a netduino), it is probably a safer bet to stick to 100 kHz (not quite
sure how the speed is set on a RasPI though).

AFAIK the TWI Slave firmware uses the lines on the I2C bus properly (i.e. by toggling
the lines between input and output).
Proper I2C device has bidirectional pins with output in open drain mode, hence the pullup resistors.
It does pull SDA and SCL high on initialization, could that be the problem?
First problem I2C devices or even masters should NEVER pull output high that is what the pull up resistor is for. Second problem output should be configured as open drain for correct I2C see the NXP spec here http://www.nxp.com/documents/user_manual/UM10204.pdf
The GPIO pins on the attiny are tri-state, and the USI slave firmware toggles between output and input (high impedance state). In the high impedance state, the port will be pulled high by the pull-up.
techpaul wrote: Any device that pulls output high means it cannot safely be used with any other device on the I2C bus, as another device could pull the output low and damage the driver.
There is no series resistor on the I2C lines, and I haven't had issues with having
it in series with several I2C devices.
More by luck than design in my personal opinion having been designing with I2C since about 1998, with many slave devices on I2C busses and some long cable lengths more than 10m.
I don't have access to my RasPI right now, but I will do some more testing here too once I get the chance.
Try the LED device as per his photos and the original post.
I will re-read the original Atmel application note when I have time: I think it is designed to follow the I2C spec, but there is obviously some compatibility issue, and I'm hoping that can be fixed in the firmware.

As I said in my post, I've tried both devices, as has OP.
techpaul wrote: To original poster I would consider getting an I2C repeater and tieing its enable input to a GPIO pin, with a 10k pull down resistor, so you can have the device isolated and enable the I2C communication when you know device has powered up and initialised it might then stand a chance of working.

You could try a FET level shifter and drive the gate of the level shifter with a GPIO pin output with a 10k pull down to ground.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: I2C device responding on all addresses

Sun Dec 30, 2012 11:16 am

akafugu wrote:The GPIO pins on the attiny are tri-state, and the USI slave firmware toggles between output and input (high impedance state). In the high impedance state, the port will be pulled high by the pull-up.
Getting both pins to be open drain would be a start.
I will re-read the original Atmel application note when I have time: I think it is designed to follow the I2C spec, but there is obviously some compatibility issue, and I'm hoping that can be fixed in the firmware.
A quick scan of that application note shows they make one pin bidirectional open and for some reason the other pin open-drain for INPUT and standard Tri-state for output, I have know application notes have mistakes in them over the years, however I would see if the pin that toggles between modes can be made open-drain for output or better still bi-directional open-drain.

Beyond that you are looking at on edge timings and firmware/interrupt latencies in the ATTiny.

One other thought has the OP tried a second Pi?
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

Return to “Interfacing (DSI, CSI, I2C, etc.)”