I2CWRITE and 18F4680

[ecoli-557]

Yes, all esle is working as expected. When I start a project I use the LCD as a debugging tool and all the messages I write to it are working. ALso the heartbeat LED is blinking showing me that I am looping in the main part and that the proc is counting correctly.

Everything BUT the I2C commands - nothing from the pin!!

[mister_e]

Well that's strange... i have activity here on both pins with the same PIC, but 20MHZ external crystal (not the problem here as your LCD work)

PBP 2.50, MPASM 5.20.

I would check for a short somewhere...

[ecoli-557]

Mr. E-
I used the 2 pins in a diagnostic way and toggled them the same way I toggle the 'heartbeat' LED. Both the data and clocks pins echoed the 'heartbeat' LED so I believe there are no shorts.
I did this before but wanted to do it again just to be sure.
if loop=<10 then low heart 'A way to turn off the heartbeat pulse
if loop=<10 then low iclock
if loop=>11 then high heart 'A way to turn on heartbeat pulse
if loop=>11 then high iclock
if loop=20 then loop=0

I will try the later version of MPASM but I don't have PBP 2.50 - yet <grin>.

[falingtrea]

First thing I noticed. According to the MCP23016 data sheet, the control byte is 0100bbbx where bbb is the device address set on the address pins and x is where the read/write bit is located. *edit The address pins I am referring to are A0, A1, and A2 (pins 16,17 and 18 on the DIP package). So for a device with all the addres pins pulled low would have a control byte of $40, with all pins set high, the control byte would be $4E.

Second you need to use the "define I2C_HOLD 1" because the MPC23016 pulls the clock low in order to signify it is not ready for the next byte of data.

Thirdly the address field of the I2C commands should be where you put the register command byte for read or write of a register. The address field should be left out if you are reading the I/O status.

Also are you using external 4.7k pullup resistors? The I2C commands set the SDA and SCL pins to tristate and only drive a low state. External pullups are needed unless you use "DEFINE I2C_SCLOUT 1" which defeats the clock hold capability of the MPC23016.

[ecoli-557]

Thanks for the input, I am confused however upon my reading (and re-reading the 23016 datasheet) writing to the config registers are:
"First, the device is selected bt sending the slave address and setting the R/W bit to logic '0'. The command byte is sent after the address and determines which register will be written." and then it shows the waveforms for this.
Address is sent 1st (according to the datasheet) and is 0-1-0-0-A2-A1-A0 and then the R/W bit. Next is the command byte (8 bits) and then the 2 data bits - Appaerntly this device uses 2 and accesses them automatically.

All of this I think I get - but it still does not answer the fact that the data and clock pins do not toggle - AT ALL! I can see if I get my sequence wrong - but the lines should still toggle.

Once I get the lines to at least toggle in some form, then I set myself to get the device to actually look like it may work.

Any other ideas?

[ecoli-557]

Mr. E-
I have updated to PBP 2.50 (we had it just not loaded) and am looking for MPASM 5.20 and don't seem to find it on Microchip's website - where did you find it?

I re-compiled with PBP 2.50 and MPASM 5.14 and get the same thing - just dead pins.......

I also added the patch so I am now using PBP 2.50A.....

[skimask]

I re-compiled with PBP 2.50 and MPASM 5.14 and get the same thing - just dead pins.......

Wondering...how do you in fact know that the pins are actually dead...i.e. not doing anything?
I know you said "by a scope" back in post #1...but what do you mean by 'scope'? A freq. meter, a 1Khz BW o-scope? A good o-scope with a decent bandwidth?
I begin to wonder if in fact the pins are really doing something, but the method you are using to see said something is faulty...because any pulses coming out of I2CC/I2CD would probably be too fast to see with an ordinary meter.

[ecoli-557]

Good thoughts, but, I am using a DSO with 100 MHz (not great but fast enough). And, remember (or not) I also remarked the coded for the I2C commands and added the same code used for the 'heartbeat' indication on an LED and watching the scope both lines followed the LED exactly. This should mean no sharts, the 23016 seems not to drag down the output of the PIC, etc.

By rights it should work - I can not see why it won't. Regardless of the code issues, if the I2C command does anything it should 'wiggle' the pin and I am not seeing it. I have put the init section in its own loop and I still don't see any activity.

My error label never gets activated so the proc thinks it is communicating with the 23016 but it is not.

What else can I try? I appreciate the assist....

[ecoli-557]

[QUOTE=
Also are you using external 4.7k pullup resistors? The I2C commands set the SDA and SCL pins to tristate and only drive a low state. External pullups are needed unless you use "DEFINE I2C_SCLOUT 1" which defeats the clock hold capability of the MPC23016.[/QUOTE]

Yes, the data and clock lines are pulled up by a 4.7k resistor each. The 3 address lines are tied low.

[ecoli-557]

First thing I noticed. According to the MCP23016 data sheet, the control byte is 0100bbbx where bbb is the device address set on the address pins and x is where the read/write bit is located. *edit The address pins I am referring to are A0, A1, and A2 (pins 16,17 and 18 on the DIP package). So for a device with all the addres pins pulled low would have a control byte of $40, with all pins set high, the control byte would be $4E.

This is a bit murky for me, if the R/W bit is bit 0 in this sequence then it would be $40. If the bit does not figure into the sequence then it would add a 0 to the 8 bit position and it would be $20.

I have tried both and the pins still do not toggle, thanks though.

[ecoli-557]

Second you need to use the "define I2C_HOLD 1" because the MPC23016 pulls the clock low in order to signify it is not ready for the next byte of data.

When I added this to the code, it locks up at the init as I suspected it would as the proc sees nothing back from the 23016 due to the proc not sending anything to it.

[ecoli-557]

Second you need to use the "define I2C_HOLD 1" because the MPC23016 pulls the clock low in order to signify it is not ready for the next byte of data.

Fallingtrea and Mr. E (hey that rhymes!) have helped me see the problem.

Mr. E noticed the enhanced bit set - this is REAL important - it screws stuff up. After that I actually had a waveform to look at. Then I noticed I wasn't getting ALL of my clock pulses only 3 chars worth. So I tried the DEFINE I2C_HOLD 1 from the book and Fallingtrea and that got all of my 4 chars of data clocked into the little sucker.

Also, Fallingtrea was also correct in that a zero addressed part is address $40 and NOT $20 as I had thought - it didn't work before due to the enhanced CPU masking everything.

I can now code myself into a corner and see how this thing really works.

Thanks guys, I knew it was simple but what an ordeal! I will have a sip of Rye in both of your honor later <grin>.

-Likin' coding once again!

[ecoli-557]

Yup Mr. E, our posts crossed in the 'ether, you do add a $40 to your addresses.....

Thanks again, this forum is great. I hope I can offer assistance in the future and repay the debt.