I2C bus "problems"

I have an UNO, a Phi-2 shield and a 20x4 LCD.
The I2C bus works, as the RTC and EEPROM work fine.

I bought an MCP 23017 IC which is am I/O expander thing which lives on the I2C bus.
I ran two wires from the Uno to another board where the chip is. The wires are about 12cm long.
The power supply is external to the Arduino - via a 7805.

Initial testing with a digital multi metre seemed to indicate it was working. The pins would cycle from 0 to 5 volts, then back to 0.

So that as it is/was, I put a couple of wires on the outputs of the MCP and ran them about 5cm to another part of the circuit - inputs to transistors to drive relays.

Connected it all back up and....... it sort of worked. Sometimes the relays would operate, sometimes not.

Throughout this the RTC was working fine as in not being corrupted. Though I can 't say the I2C bus was not hanging as I wasn't able to get the time displayed and test the MCP at the same time.

At that stage there were no pull UP resistors on the board where the MCP is. Searching I found 4k7 would be nominal. So I put 2 x 4k7 resistors in where I didn't expect to be putting them.

Plugged in, NOTHING!

At one stage I put the SDA and SCL back to front - via header pins to allow easy board removal. I don't think that would be a problem, and I realised and rectified the mistake.
If I am lucky the relays function, but that is about 1 in 100 sucess. Not really good enough.

I've checked the supply and it is 5v to the MCP.

Anyone got any ideas on how to better check what is going on?

The sketch I am using is the example sketch which came from macegr's website for the centipede library.

lost_and_confused:
I ran two wires from the Uno to another board where the chip is. The wires are about 12cm long.

Plus ground?

So I put 2 x 4k7 resistors in where I didn't expect to be putting them.

Where was that then? It should be between the signal line and +5V.

Nick,

Well the ground is common.

I have a 12v SMPS powering both the Arduino and the other board. So ground is good.

Grumpy:
I meant when I "designed" the layout I didn't really leave room/space for 2 resistors.
Yes between the SCL and SDA to +5 rail.

Phi-2 shield : Phi-2 shield | LiuDr Electronic Solutions LLC Official Blog
Does this Phi-2 shield have I2C pull-up resistors ?
The total pull-up impedance should be 4k7 for the best results.

MCP23017 : http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en023499

If you only use that MCP23017, is that working ?
Do you use 100nF on the +5V at the MCP23017 ?
Wires of 12cm should be okay, but are they seperated wires (good) or tied together (bad).
Are the transistors and relays pulling to much current ?

My guess is some voltage spike or too much current drawn which makes the MCP13017 go wrong.

Krodal,

Good questions.

RE: Phi shield. Little help/support now. Don't know why.
Schematics not available. Don't know if there are pull up resistors or not, but I'd have at a guess no.

Yeah, got the docs/pdf. Sort of helpful. The RESET line is interesting.
On one page it is an OUTPUT, and on another it is an INPUT, so that has me a bit confused.
But! It does have "power on reset" so that is good.
Haven't tried ONLY the MCP. Didn't have time and sort of didn't think of it.
May try tonight if I have time.
I did put a cap - not sure what size but it would be around the right value - on the output of the 7805.
Alas the wires are two bits of an old ribbon cable. I can't see how/why they would be two discreet wires. Anyway....
The transistors and relays are seperated from the MCP because they run on 12V and the supply is a 12 V 2 A SMPS. So I hope that has the chop.

The input to the transistos shouldn't be too much. They used to be powered from an old digital clock chip - straight off the IC. That lasted for about 20 years.

I guess time will tell what is going on.

The only other interesting thing which you reminded me of with "spike":
When the MCP was (supposedly) working when I was looking at it with the multi metre, when the pins went from 0 to +5, I was sure I saw a 36V spike. But I am putting it down to 3.6 and I just didn't see the decimal point.
This was on the OUTPUT of the MCP.

Update:

Got home and tried a few things.

Removed all the other shields from the Arduino and only connected the I2C bus.

Ran the test program and "zilch".

Nothing happening on the output pins of the MCP.

I really hope it isn't kaput. Although not that expensive, it was painful getting it.

Checked the voltage, and it is 5.09 Vdc on it's power pins.

Just one thing though:
The address pins. Do I tie them high or low to make the address "zero"?

I tied them low.

Yes, low for address zero.

Also make sure you tie the ~RESET line high.

What are the commands you are sending to the chip to test it?

There are a few things to do.

Don't use ribbon cable for I2C and use two 100nF for the 7805. Every test will be useless until you have this right. I'm serious!
By using a ribbon cable you create some kind of twisted pair for the I2C-bus. The SCL and SDA lines can't handle that. Use two seperate wires.
The 7805 needs a 100nF at the input and 100nF at the output, and they should be near the 7805. You can ofcourse add extra capacitors to those 100nF's. If you only knew how much people had problems by a badly decoupled 7805 .......

Run an i2c_scanner to detect the devices: http://arduino.cc/playground/Main/I2cScanner
If you have it stable working, add the other I2C devices, and it must/should all work together.

Perhaps the base current of the transistors might influence your +5V power. That depends on your circuit.

Your I/O expander chip has decoupling capacitor right? If not all bets are off. SImilarly the relay supply is decoupled? The relay windings have diodes across them?

Note:
I goofed.
During the build, I accidently tied the address lines LOW. Oops. I realised that when I was taking the piccies.
At that time I was also told to tie the reset line HIGH.
So I had to reposition the 3 address lines and add the reset line.

Though having done that and re-assembled the board, still no joy.

Here are some piccies.

Now, what is what on the piccie:
Red line: +5 volt line for MCP and address lines and reset line.
Black line - just below red one: 0 v line.
Red arrow: Indicate pin 1 on MCP
Green loop: I2C input
Purple loop: Outputs
Orange loop: address and reset lines (they go over to the red line)
Green arrow: 7805
Orange arrow: cap on output
Purple arrow: I2C pull up resistor. There is also one on the underside of the board on the other line.

Further note:
While looking at the piccie I noticed a "short" where the track had not been cut between pin 14 and 15 on the MCP.
VERY subtle thing. Shall report back if anything changes.
But I was looking/testing pins 1,2 and 3. NONE of them changed state.
But as 14 is "N/C" I am not sure what that would mean, do.
P.S.
None of the N/C pins are connected to anything.

Makenko:
This is the sketch:

// Example code for Centipede Library
// Works with Centipede Shield or MCP23017 on Arduino I2C port
 
#include <Wire.h>
#include <Centipede.h>
 
 
/* Available commands
  .digitalWrite([0...127], [LOW...HIGH]) - Acts like normal digitalWrite
  .digitalRead([0...127]) - Acts like normal digitalRead
  .pinMode([0...127], [INPUT...OUTPUT]) - Acts like normal pinMode
  .portWrite([0...7], [0...65535]) - Writes 16-bit value to one port (chip)
  .portRead([0...7]) - Reads 16-bit value from one port (chip)
  .portMode([0...7], [0...65535]) - Write I/O mask to one port (chip)
  .pinPullup([0...127], [LOW...HIGH]) - Sets pullup on input pin
  .portPullup([0...7], [0...65535]) - Sets pullups on one port (chip)
  .init() - Sets all registers to initial values
 
  Examples
  CS.init();
  CS.pinMode(0,OUTPUT);
  CS.digitalWrite(0, HIGH);
  int recpin = CS.digitalRead(0);
  CS.portMode(0, 0b0111111001111110); // 0 = output, 1 = input
  CS.portWrite(0, 0b1000000110000001); // 0 = LOW, 1 = HIGH
  int recport = CS.portRead(0);
  CS.pinPullup(1,HIGH);
  CS.portPullup(0, 0b0111111001111110); // 0 = no pullup, 1 = pullup
*/
 
Centipede CS; // create Centipede object
 
 
void setup()
{
  Wire.begin(); // start I2C
 
  CS.initialize(); // set all registers to default
 
  CS.portMode(0, 0b0000000000000000); // set all pins on chip 0 to output
 
  pinMode(13,OUTPUT);
  //TWBR = 12; // uncomment for 400KHz I2C (on 16MHz Arduinos)
 
}
 
 
void loop()
{  
    while (1)
    {
        CS.digitalWrite(0,HIGH);
        digitalWrite(13,HIGH);
        delay(3000);
        CS.digitalWrite(0,LOW);
        digitalWrite(13,LOW);
        delay(3000);
        CS.digitalWrite(1,HIGH);
        digitalWrite(13,HIGH);
        delay(3000);
        CS.digitalWrite(1,LOW);
        digitalWrite(13,LOW);
        delay(3000);
        CS.digitalWrite(2,HIGH);
        digitalWrite(13,HIGH);
        delay(3000);
        CS.digitalWrite(2,LOW);
        digitalWrite(13,LOW);
        delay(3000);
    }
}

It doesn't yield any outputs from the pins.

Krodal/MarkT:
The 12 side of things is sort of like this:
12v 2A SMPS
1 - Arduino and 2 shields.
2 - Vero board
3 - (not yet connected)

Vero board:
12 v in.
2 x "relay drive circuits" which are two transistors arranged darlington style to drive a small 2p2t/co relay.
Flyback diodes, etc ALL included.
One of the contacts from said relay then goes to drive another 12v relay with 240V contacts AND light an LED.
The LED also has a small "trickle voltage constantly so it "glows in the dark" - making it easier to see/find.
(See http://arduino.cc/forum/index.php/topic,113214.new.html#new ) since resolved.
The other (second) relay with the 240 volt contacts also has flyback diodes on it/them.
The 7805 is powered from the 12v rail - no decoupling. I tried two caps and they died after I went to extreme lengths to put them on/in the circuit. I'm guessing that because they are 15+ years old didn't help.
So, there is the small blue cap which is on the output of the 7805 - see picture in previous post.
There is nothing else on the output of the 7805 and it ONLY powers this MCP chip and associated resistors which go to the MPC's pins anyway.

Now a question about the I2C bus wires:
Ok, ribbon cable is not a good thing. But I have two wires going from one place - beside each other - to another place, arriving beside each other. Using two "discreet" wires would be annoying in that they wouldn't stay together and so would cause problems in that sense - or something like that.

Anyway, I need to get back to things and cut that track better and use that test sketch and see what happens.

TTYL.

Ran the I2C scanner sketch.

This is what I got:

Scanning...
I2C device found at address 0x27 !
I2C device found at address 0x50 !
I2C device found at address 0x68 !
done

I have (knowingly)
RTC chip
EEPROM
And that's it.

My MCP but the address is "unknown" - though I have all the pins to HIGH.

So are any of the devices at the addresses you expect?

An EEPROM can look like two addresses.

In the underside photo on the line with the pull up, seven tracks to the right looks like a solder splash joining adjacent tracks.

As you have three addresses on the scan it looks like your hardware is working so write some simple software to test the chips.
If that dosn't work then post that code.

Mike:
Thanks.

The code is posted and doesn't work.

The addresses are unknown to me, the fact I am getting three "I am here"'s back is good to see.

Slight update and sorry for the delay in not declaring it.

I too was wondering "how do I know the MCP is working?"

So: While the script was running I disconnected the I2C bus from the MCP.

Voila! I lost one of the "found devices". Which one I forget.

But to me, it kind of verifies that the MCP is "alive" and hasn't spat the dummy.

I can't see any referance to an I2C address in that code.

You have no need for the while loop the whole loop function repeaters.

Why not ditch the libary and write some real code.

Well, if I am not mistaken it is the centipede library of which we are speaking.

The simplicity of just sending bits to the library which does all the hard work seems a bit easier to me than "bit bashing" things out on the I2C bus.

It also allows easy set up of inputs and outputs.

So at this point in time, it seems the easier way to do it.

As to writing "real code" well, for now I shall leave that to the experts and not take that sort of stuff on.
Writing the code/s I need is difficult enough.

I have two projects on the go now and there are more in the system to be born.

So: With the new information that if I disconnect the I2C bus I lose one of the devices, but I can't seem to get the pins going high.

Next idea?

Sure it is simple, it simply does not work. Because the address is hidden if you don't wire it up exactly like the libary is expecting then it won't work.
So you need to find out what the libary is expecting the external address lines to be and wire it up like that.

It (the library) is expecting the MCP to be at 20 hex.

So the device found at 27Hex is the MCP - and is the address I lost when I unplugged the MCP.

Thinking a bit, each MCP device is 0 - 15, 16 - 31, and so on.

So device 7 would be.......

(7 * 16) = .......
112?
So if I change the code to write to 112 and on, I may see outputs.

Ofcourse the question is why I was told to tie the address lines HIGH to make it address 0.
(Rhetorical in ways)
But no love lost.

All part of the learning curve.

And it is slightly flattening out for me now.

Who told you to tie the address lines high for address 0? In my post I said low for address 0 and tie reset high. Why did you tie address lines high???