mcp23016 issues with my bs2p24 :/

trend · 2005-01-11 01:59

/edit 1/14/05
The issue now isn't the code.. nor the mcp.
It is when we control a relay (through the uln2803a to the mcp23016) and try to control AC current, we get ~50percent sucessrate.. but when we try to control DC, we get nearlly 100percent sucess rate

When controlling AC current.. when the mcp "fails" to close the relay to allow AC.. I still hear the relay close, just the motor doesn't spin..
/end of edit

Hello, I am trying to figure out why my code below works only ~80-90percent of the time... 10-20percent of the time, the mcp23016 doesn't change the output state of the pins·while it is in the loop.

here is my code:

' {$STAMP BS2p}
' {$PBASIC 2.5}
SDA     PIN 0         'MCP.15
SCL     PIN 1         'MCP.14
DevType         CON     %0100 << 4               ' Device type
DevAddr2        CON     %001 << 1                ' Address = %001
DevAddr3        CON     %100 << 1                ' Address = %100
WrMCP2          CON     %01000110                ' Write to MCP2
RdMCP2          CON     %01000111                ' Read from MCP2
WrMCP3          CON     %01000010                ' Write to MCP3
RdMCP3          CON     %01000011                ' Read from MCP3
GP0             CON     $00                      ' register addresses
GP1             CON     $01
OLAT0           CON     $02
OLAT1           CON     $03
IPOL0           CON     $04
IPOL1           CON     $05
IODIR0          CON     $06
IODIR1          CON     $07
INTCAP0         CON     $08
INTCAP1         CON     $09
IOCON0          CON     $0A
IOCON1          CON     $0B

dataGP0         VAR     Byte                    ' device I/O bank 0
dataGP1         VAR     Byte                    ' -- bank 1
com             VAR     Byte
idx             VAR     Nib                     ' loop counter
 
  I2COUT SDA, WrMCP2, IODIR0, [noparse][[/noparse]%00000000]      ' MCP2 GPO pins are outputs
  I2COUT SDA, WrMCP2, IODIR1, [noparse][[/noparse]%00000000]      ' MCP2 GP1 pins are outputs
  I2COUT SDA, WrMCP3, IODIR0, [noparse][[/noparse]%00000000]      ' MCP3 GPO pins are outputs
  I2COUT SDA, WrMCP3, IODIR1, [noparse][[/noparse]%00000000]      ' MCP3 GP1 pins are outputs
top:
  'Set states of MCP2 and MCP3
  I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.

dataGP0 = 128
I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]dataGP0]
PAUSE 1000 'not sure about the delay needed.. but i am sure 1 sec is fine :)
I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]dataGP0]
PAUSE 2000
GOTO top

Am I missing anything/need to change anything?

Also, how can I check the pin state through i2cin?

thanks again guys!
Lee

Post Edited (trend) : 1/14/2005 5:35:29 PM GMT

trend · 2005-01-11 03:15

Oh yeah.. and eventually the problem gets worse (less and less of bringing the pins high).. then I just have to unplug the power to the mcp23016/bs2 and then it acts normal (normal = intermitted problems)

Jon Williams · 2005-01-11 04:12

Are you following the Rext and Cext recommendations of 3.9K and 33pF? I use those values and have never had a problem with the MCP23016.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

trend · 2005-01-11 04:35

Yep.. attached is my schematic for my device..

thanks for the help Jon!

Lee

trend · 2005-01-11 07:14

So the code should work fine?

how would I verify what pins are high/low inputs/outputs?

thanks-Lee

Jon Williams · 2005-01-11 13:31

The documentation makes it pretty clear, I think. To check the IO direction on the pins you would read back the IODIRx registers; to check the output state of the pins you read back the OLATx (output latch) registers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

trend · 2005-01-11 20:47

Yeah.. I think something is weird with my board.. I write something to the chip, and when I try to read what state the mcp is in.. it acts like I never told the mcp what to do.. And the problem gets worse and worse until I unplug the unit..

Anyways, I used this code.. Hope it might help other people out with similiar debugging:

' {$STAMP BS2p}
' {$PBASIC 2.5}
SDA     PIN 0         'MCP.15
SCL     PIN 1         'MCP.14
DevType         CON     %0100 << 4               ' Device type
DevAddr2        CON     %001 << 1                ' Address = %001
DevAddr3        CON     %100 << 1                ' Address = %100
WrMCP2          CON     %01000110                ' Write to MCP2
RdMCP2          CON     %01000111                ' Read from MCP2
WrMCP3          CON     %01000010                ' Write to MCP3
RdMCP3          CON     %01000011                ' Read from MCP3
GP0             CON     $00                      ' register addresses
GP1             CON     $01
OLAT0           CON     $02
OLAT1           CON     $03
IPOL0           CON     $04
IPOL1           CON     $05
IODIR0          CON     $06
IODIR1          CON     $07
INTCAP0         CON     $08
INTCAP1         CON     $09
IOCON0          CON     $0A
IOCON1          CON     $0B
dataGP0         VAR     Byte                    ' device I/O bank 0
dataGP1         VAR     Byte                    ' -- bank 1
dataGP2         VAR     Byte                    'this is to verify correct hign on mcp
com             VAR     Byte
idx             VAR     Nib                     ' loop counter

top:
  I2COUT SDA, WrMCP2, IODIR0, [noparse][[/noparse]%00000000]      ' MCP2 GPO pins are outputs
  I2COUT SDA, WrMCP2, IODIR1, [noparse][[/noparse]%00000000]      ' MCP2 GP1 pins are outputs
  I2COUT SDA, WrMCP3, IODIR0, [noparse][[/noparse]%00000000]      ' MCP3 GPO pins are outputs
  I2COUT SDA, WrMCP3, IODIR1, [noparse][[/noparse]%00000000]      ' MCP3 GP1 pins are outputs

  'Set states of MCP2 and MCP3
  I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.
dataGP0 = 16
PAUSE 1000
I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]dataGP0]
DEBUG "OLAT verified: "
I2CIN SDA, RdMCP2, OLAT0, [noparse][[/noparse]dataGP2]
  IF dataGP2 <> dataGP0 THEN
  DEBUG "failed.. resetting", CR
  GOTO top
  ENDIF
DEBUG "success", CR
PAUSE 100

DEBUG "IODIR verified: "
  I2CIN SDA, RdMCP2, IODIR0, [noparse][[/noparse]dataGP1]
    IF dataGP1 <> %00000000 THEN
    DEBUG "failed.. resetting", CR
    GOTO top
    ENDIF
  IF dataGP1 = %00000000 THEN DEBUG "success", CR
 

PAUSE 3000

  I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.

·I am about to see what is going wrong with the hardware..

·

trend · 2005-01-12 01:52

Weird.. it looks like the mcp23016 is error proned when the uln2803a is hooked up (and the relays hooked up to that).. (so like in the schematic).

I just ran my above code 10x or so without error when the mcp23016 didn't have the uln2803a powered.

I would power my uln2803a.. but I don't have a 12v rectifier

and radioshack just closed. So i cannot trace the problem down anymore

Does anyone have any experience with something like this happening?

thanks again!

Paul Baker · 2005-01-12 05:23

As a general note, the fact that the problem increases with time makes me think that thermal issues may be the culprit, do any parts feel excessively warm (especially the voltage regulator or your wallwart)? If you overdrive either it can cause intermitant problems that grow in frequency as time passes. Check the voltage supply coming from the regulator, and the current draw. If the voltage sags or the current is above what the regulator or wallwart is rated for, this is likely your problem. Relays are notoriously power hungry.

Post Edited (Paul Baker) : 1/12/2005 5:25:59 AM GMT

trend · 2005-01-12 05:44

interesting.. I didn't think about feeling the power supply.. but the 12v power supply (for bs2 and uln2803a and relays) wasn't warm at all when I had to unplug it all those times.. and the 6v power supply is rated at 6amps...

but I did touch one of the mcp23016 (there are 2 on the i2c bus).. and the mcp and uln was hot.. I didn't check the temperature of the other one. The reason I checked the temp of the mcp/uln was because somehow 3 of the pins went high for no apparent reason (this was when I was telling another line to go high over and over again..without the line actually going high).

thanks for the idea
Lee

Paul Baker · 2005-01-12 17:26

Are you using a regulated 12V supply? If not you'll likely need to add a 12V LDO regulator, unregulated 12V supplies will frequently output something higher (in the 14V range). You may be overdriving the voltage to your mcp/uln causing your problem.

trend · 2005-01-12 20:01

I am not sure about the psu regulator.. I will look into that

Both mcp23016s act the same way.· I already replaced the 2803. So we should be fine with that.

I took off the mcp23016's boards and put them on a breadboard.. and hooked up the output of the uln2803a to a Bar Graph Display:
http://www.radioshack.com/product.asp?catalog%5Fname=CTLG&category%5Fname=CTLG%5F011%5F006%5F001%5F000&product%5Fid=276%2D081&site=search

And I wrote a program that·brings high·each pin of the mcp23016 for 100ms, then goes to the next pin.· This program goes through GP0 and GP1.
And everything works great.· I see the leds going and going and going around in circles.

Here is a pic of what I mean:
http://webpages.charter.net/trend/bar_graph_test.jpg
·
There is a 5v and 12rectifier.. so I am emulating my relay board fairly well.
·
·
Any ideas?
·
thanks-Lee

trend · 2005-01-12 20:47

I don't believe I have a 12 regulator on the board.. That might be the issue (?).. because right now I am using a 12v regulator on my breadboard to test out the 2803a/mcp23016 Isolated from the relays...

hmm.. I guess I can go get the 12v power supply I was using for the relay board

Hope you are right!

thanks-Lee

trend · 2005-01-12 21:48

Nope, the power supply is fine without a regulator... It is measured at 12.18~vdc.. so pretty close.. And it works flawlessly with or without a rectifier.

Good idea though

Thanks-Lee

trend · 2005-01-12 21:55

hmm.. well As soon as I plug in the 12v power supply (this is power to the hole system.. I use one rectifier to get 5v output), I get:

GP1: 1
OLAT verified: success
IODIR verified: failed.. resetting...END

I get that pretty consistantly when I first plug the power supply in.. but I rememedy that by just pressing the "play button" to upload my code to the bs2 from my computer (after I plug in the power supply ;/ ), and it starts to execute the code flawlessly.

Is this normal? Should I worry about this?

allanlane5 · 2005-01-13 15:16

1. I don't see from your code why it should 'END'. Shouldn't it just re-try from "top:" forever?

2. You don't set a default state for SA or the other write pins. This means the first I2COUT (which WILL set them as outputs, by the way) may garble the first bit.

3. It's possible the 12V is coming up 'slowly'. A PAUSE 200 in the start of your program may give stuff time to get stable.

trend · 2005-01-13 16:02

Sorry, Iwas using diff code there.· This program cycles through each pin bringing them high then back to low.

' {$STAMP BS2p}
' {$PBASIC 2.5}
SDA     PIN 0         'MCP.15
SCL     PIN 1         'MCP.14
DevType         CON     %0100 << 4               ' Device type
DevAddr2        CON     %001 << 1                ' Address = %001
DevAddr3        CON     %100 << 1                ' Address = %100
WrMCP2          CON     %01000110                ' Write to MCP2
RdMCP2          CON     %01000111                ' Read from MCP2
WrMCP3          CON     %01000010                ' Write to MCP3
RdMCP3          CON     %01000011                ' Read from MCP3
GP0             CON     $00                      ' register addresses
GP1             CON     $01
OLAT0           CON     $02
OLAT1           CON     $03
IPOL0           CON     $04
IPOL1           CON     $05
IODIR0          CON     $06
IODIR1          CON     $07
INTCAP0         CON     $08
INTCAP1         CON     $09
IOCON0          CON     $0A
IOCON1          CON     $0B
dataGP0         VAR     Byte                    ' device I/O bank 0
dataGP1         VAR     Byte                    ' -- bank 1
dataGP2         VAR     Byte                    'this is to verify correct hign on mcp
com             VAR     Byte
idx             VAR     Nib                     ' loop counter
x               VAR     Byte
x=1
  'I2COUT SDA, WrMCP2, IODIR0, [noparse][[/noparse]%00000000]      ' MCP2 GPO pins are outputs
  'I2COUT SDA, WrMCP2, IODIR1, [noparse][[/noparse]%00000000]      ' MCP2 GP1 pins are outputs
  I2COUT SDA, WrMCP3, IODIR0, [noparse][[/noparse]%00000000]      ' MCP3 GPO pins are outputs
top:
  I2COUT SDA, WrMCP3, IODIR1, [noparse][[/noparse]%00000000]      ' MCP3 GP1 pins are outputs

  'Set states of MCP2 and MCP3
  'I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.
 
dataGP0 = x
IF x = 0 THEN
  x = 1
  GOTO N3XT
  ENDIF
x=x*2

DEBUG "GP1: "
DEBUG DEC dataGP0, CR
PAUSE 100
I2COUT SDA, WrMCP3, GP1, [noparse][[/noparse]dataGP0]
DEBUG "OLAT verified: "
I2CIN SDA, RdMCP3, OLAT1, [noparse][[/noparse]dataGP2]
  IF dataGP2 <> dataGP0 THEN
  DEBUG "failed.. resetting..."
  GOTO Failed
  ENDIF
DEBUG "success", CR
PAUSE 100

DEBUG "IODIR verified: "
  I2CIN SDA, RdMCP3, IODIR1, [noparse][[/noparse]dataGP1]
    IF dataGP1 <> %00000000 THEN
    DEBUG "failed.. resetting..."
    GOTO Failed
    ENDIF
  IF dataGP1 = %00000000 THEN DEBUG "success", CR
 

PAUSE 300

 ' I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.
 

  GOTO top
 

N3XT:
'x=1
N3RT:
  I2COUT SDA, WrMCP3, IODIR0, [noparse][[/noparse]%00000000]      ' MCP3 GPO pins are outputs
  'I2COUT SDA, WrMCP2, IODIR1, [noparse][[/noparse]%00000000]      ' MCP3 GP1 pins are outputs

  'Set states of MCP2 and MCP3
  'I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.
dataGP0 = x
IF x = 0 THEN
x=1
GOTO top
ENDIF
x=x*2

DEBUG "GP0: "
DEBUG DEC dataGP0, CR
PAUSE 100
I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]dataGP0]
DEBUG "OLAT verified: "
I2CIN SDA, RdMCP3, OLAT0, [noparse][[/noparse]dataGP2]
  IF dataGP2 <> dataGP0 THEN
  DEBUG "failed.. resetting..."
  GOTO Failed
  ENDIF
DEBUG "success", CR
PAUSE 100

DEBUG "IODIR verified: "
  I2CIN SDA, RdMCP3, IODIR0, [noparse][[/noparse]dataGP1]
    IF dataGP1 <> %00000000 THEN
    DEBUG "failed.. resetting..."
    GOTO Failed
    ENDIF
  IF dataGP1 = %00000000 THEN DEBUG "success", CR
 

PAUSE 300

 ' I2COUT SDA, WrMCP2, GP0, [noparse][[/noparse]0, 0]      'Set all MCP2 outputs low.
  I2COUT SDA, WrMCP3, GP0, [noparse][[/noparse]0, 0]      'Set all MCP3 outputs low.

GOTO N3RT
Failed:

DNE:
DEBUG "END"

I don't understand what you mean by:

2. You don't set a default state for SA or the other write pins. This means the first I2COUT (which WILL set them as outputs, by the way) may garble the first bit.

and on point 3. great answer. I thought that might be the problem.. but for some reason I didnt' see putting a pause 200 in there to fix the problem

thanks! Lee

trend · 2005-01-13 16:07

oh yeah.. and in some of the code I am using.. I am testing out different boards "mcp2" or "mcp3".

But I do believe I am telling the mcp to set all the pins to outputs. Were you saying I wasn't doing something else?

thanks-Lee

allanlane5 · 2005-01-13 16:55

Yes. What is the default state of the 'SA' and 'SC' pins?
(These are P0 and P1 from your code).

Should they be 'LOW' when idle? 'HIGH' when idle? Inputs when idle?
The I2COut command will leave them in some 'idle' state. If they are not in that idle state on your first I2COUT command, then the device recieving the first I2COut command may get an extra bit, or miss the first bit.

This may not be an issue with what you are doing. I notice you are now issuing the I2COUT command twice when your program starts up, so that should take care of the issue.

trend · 2005-01-13 18:36

I believe I figured out the issue... Just clueless on how to resolve the problem..

Like I have said above, the uln2803a drives relays (I believe js1-12v...
http://rocky.digikey.com/WebLib/Aromat/Web%20Data/JS%20Relays.pdf·)

Everything works fine as long as there is no power going into Com/NO/NC pins (I am not sure if I said that right.. but basically I unplug my 27vAC 1.3amp powersupply so the relays cannot distribute power to the intended motor).

I have left my program go on for a couple minutes, and the mcp can be written to and read from flawlessly.... But as soon as I plug in the 27vAC 1.3amp power supply, the mcp only operates correctly ~1/3 of the time.

Do you'll have any ideas?

thanks! Lee

Jim McCorison · 2005-01-13 19:38

Lee,

I'm pretty new to this, so please forgive this attempt if I'm out in left field somewhere.

The specs on the js1-12 relay give a nominal operating current of 30ma. The specs on the mcp23016 say it can handle 25ma. From the looks of it you are trying to source more current out of the mcp23016 then it is designed to handle.

Jim

Newzed · 2005-01-13 19:43

Lee is using the MCP to drive a ULN2803 which drives the relays, so relay current has no effect on the MCP.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Do you have a Stamp Tester?

http://hometown.aol.com/newzed/index.html
·

trend · 2005-01-13 19:44

Yeah, but the uln2803a is inbetween the mcp and the relays.. Also, if the mcp was hooked directly up to the js1-12.. the mcp couldn't output the 12v needed to close/open the relay.

thanks for the suggestion though!

trend · 2005-01-13 19:52

Now I think about it.. the 27vAC power supply might not be 1.3amps

Would this have an effect on the situation?

thanks-Lee

Newzed · 2005-01-13 20:01

Lee, can you hook a DC device to the relay instead of the 27VAC· There is a possibility that the AC going thru the relay contacts might be getting back to the MCP and throwing the clock off.· Your big DC motor draws to much current to connect to the relays - do you have any thing else?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Do you have a Stamp Tester?

http://hometown.aol.com/newzed/index.html
·

trend · 2005-01-13 20:06

The resistance between the coils of the motor is 188.. And The Power supply outputs 27vAC.

AND Ohms = Volts / Amps

So the motor operates off ~7 amps

/side note.. the power supply and motors were designed for each other.. That is why I can do the above
/end

So this should still let me operate within the limits of the relay, right?

thanks-Lee

trend · 2005-01-13 20:08

Yeah, I have those 2 DC solenoids already hooked up relays 31 and 32.. I have only run the solenoids a couple of times. Those work fine.. I would hate to run those for 2 minutes straight though to make sure everything is flawless.

Newzed · 2005-01-13 20:12

Lee, solenoids are designed to stay closed for long periods of time.· You can run those solenoids for an hour and it wouldn't hurt them.

What we have to determine is if the MCP operates OK if there is a DC device on the relay, but fails when you put an AC device on the same relay.· Let's do it [noparse]:)[/noparse])

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Do you have a Stamp Tester?

http://hometown.aol.com/newzed/index.html
·

trend · 2005-01-13 20:15

Ok, I will go test the DC relays.. same operating time (1sec relay open, 3sec closed).. and I will loop this sequence for a minute or 2..

So be back in 5 minutes

Jim McCorison · 2005-01-13 20:22

Lee said...
Yeah, but the uln2803a is inbetween the mcp and the relays..

Doh!

trend · 2005-01-13 20:34

hah... I just got finished testing the dc solenoid via open/closing the relay... and it still fails with this.

It ran through the test 2 whole loops before an error and i got something like this:
9or8 sucessfull open/closes then the mcp verify state (olat or direction) doesn't verify

any ideas?

mcp23016 issues with my bs2p24 :/

Comments