I2C blues

[Charles Linquis]

I can't figure out what is going on in the code below. I'm trying to talk to a
24FC512 EEPROM. I can't get anything to work. Pull ups on SCL and SDA are
2.2K. This signals look great on an analog scope.

The output from my MCC I2C analyzer is below the code segment.

I'm using PBP2.6, processor is 18F8723@40Mhz.

What am I doing wrong?




DEFINE I2C_SLOW 1
...
EEAddr = %10101010

TOPP:
For XX = 0 to 255 ; XX is a WORD variable
Y = $AA ; Y is a BYTE variable
; EEAddr is a BYTE variable

I2CWRITE PortD.6,PortD.5,EEAddr,XX,[Y]
pause 10
next XX
pause 1000
goto topp




Msg 1017 [Start]#AA[W][Stop]
Msg 1018 [Start]#A0[W]AA[Stop]
Msg 1019 [Start]#AA[W][Stop]
Msg 1020 [Start]#A0[W]AA[Stop]
Msg 1021 [Start]#AA[W][Stop]
Msg 1022 [Start]#A2[W][Stop]
Msg 1023 [Start]#AA[W][Stop]
Msg 1024 [Start]#A2[W][Stop]
Msg 1025 [Start]#AA[W][Stop]
Msg 1026 [Start]#A4[W][Stop]
Msg 1027 [Start]#AA[W][Stop]
Msg 1028 [Start]#A4[W][Stop]
Msg 1029 [Start]#AA[W][Stop]
Msg 1030 [Start]#A6[W][Stop]
Msg 1031 [Start]#AA[W][Stop]
Msg 1032 [Start]#A6[W][Stop]

[mackrackit]

I am sure you have checked, but are the connections to A0-A1-A2 solid?
That output makes me wonder.

[circuitpro]

You have the address configured as device 5. PortD.6 is SDA, PortD.5 is SCL. Is that correct? I always use 4.7K pullups on the I2C lines too. You might try making them a little less stiff.

[Bill Legge]

Suggest you check:

1. 4.7k pull-ups not 2.2k - may not make any difference but will elliminate a possibility. I know 10k pull-ups work at low speed but not 40MHz.

2. Address you are using is: 101, are the chip pins set accordingly?

3. A 512k EEPROM must have a word size address, is XX definately a word size variable?

4. Is the write-protect pin grounded to enable writing?

Regards Bill Legge

[Charles Linquis]

I tried 10K pull-ups (no joy) and my program scanned all the addresses.

For X = 0 to 7
Address = $A0 + (X<<1)
...

The internal device address ("command") was definitely a WORD variable.

But I *DID* find something very interesting: Whenever the MSb (A2) of the EEPROM was brought high, the device stopped responding. Addresses $A0,$A2,$A4,$A6 all worked. $A8,$AA,$AC and $AE didn't. This happened on two separate devices (both were Microchip 24FC512's from the same lot).

Tomorrow AM, I'll find out more.

And for those playing with I2C, I found out the hard way that if you invoke DEFINE I2C_HOLD 1 and something holds SCL low (like a remote device with a diode clamp to ITS Vcc and it loses power), there is no timeout. Your program hangs forever. An email to MELABS support got me a quick answer (from a familiar person). Solution: if you are using the HOLD option, test for SCL HIGH before you invoke any I2CWRITE command.

[Bill Legge]

CL,

What is a 'MCC I2C analyzer?'

Regards Bill Legge

[Charles Linquis]

http://www.mcc-us.com/MIIC-101-DS.htm

[Bill Legge]

CL,

Thanks - I've had a look at the site/product - a bit pricey for me as only an occasional/hobby I2C user. The Australian magazine 'Silicon Chip' had an I2C analysis board as a do-it-yourself project about a year ago. It used pretty mendane chips and some free Phillips software; I must give it a go.

Can you run your system at 10MHz and see if that does the trick?

Please let us know when/if you get it going. I spent ages getting familiar with EEPROM I2C and would like to learn what the problem was.

Regards Bill legge

[mackrackit]

Hey Charles,

If you are still having trouble try changing EEADR to %10100000 and to tie A0,A1, and A2 on the eeprom chip to ground.

If that does not work then try it with and without the I2C_slow setting.

[Charles Linquis]

I talked the customer out of the feature that required it, so I just moved on. I'll get back to it later.

I was going to use the EEPROM as a "dual port RAM". The customer wanted to write data to me via I2C, so my PIC would have had to be an I2C slave. Rather than go through the hassle of that, I was just going to have them write to my EEPROM (they had access to the same SCL and SDA lines), and then I would occasionally read the same location. If I got an error during read (because they were writing at the same time), I would just read again. I told the customer that they would have to verify every read that they did. Since the data changed only every few seconds, I figured that this was a great way to get the job done.

Until I found that I couldn't write to or read from my own EEPROM!

I'll let you know what I find. It will be a few days before I get back to this.