Problem with I2C (24c32 eeprom)

[lab310]

I know that there been many questions about i2c, but i have problem and can't solve it without help - sample code for reading/writing to eeprom doesn't work for me:

SO con 0 ' Define serial output pin
DPIN var PORTD.4 ' I2C data pin
CPIN var PORTD.3 ' I2C clock pin
B0 var byte
B1 var byte
B2 var byte

For B0 = 0 To 15 ' Loop 16 times
I2CWRITE DPIN,CPIN,$A0,B0,[B0] ' Write each location's address to itself
Pause 10 ' Delay 10ms after each write
Next B0
Loop: For B0 = 0 To 15 Step 2 ' Loop 8 times
I2CREAD DPIN,CPIN,$A0,B0,[B1,B2] ' Read 2 locations in a row
Serout SO, N2400, [#B1," ",#B2," "] ' Print 2 locations
Next B0
Serout SO, N2400, [10] ' Print linefeed
Goto loop


All I get is bunch of "255", which is wrong value. It seems neither writing or reading work. I tried with pull-ups on SDA, SCL (tried 10K and 4.7K) and no change. Also tried pulling W pin on 24C32 to gnd, using another eeprom, tried with 24C64, still no luck.I'm using 16F877A on 20MHz and PBP 2.42 version.

What should I try next?

[Tom Gonser]

I have a similar issue, but have an idea that might help a little..

Have you added a 'failed' lable routine to the I2Cread or write command so you can tell if it is failing ..?

I use this:

I2CWRITE DPIN,CPIN,Chip1,Address,[STR array\36],failw

and

I2CREAD DPIN,CPIN,Chip2,address,[STR array\36],failr

... program ....


failw:
Serout2 SO,BD,["Write Failed",10,13] ' Spaces
return

failr:
Serout2 SO,BD,["Read Failed",10,13] ' Spaces
return

Where 'failw is a routine that tells me what happened.

HOWEVER!! I have the same problem you are having - no I2C data!! I have just moved to an 18F2525, and cannot for the life of me figure out how to turn on the settings for I2C on C3, C4 which are the SLC and SDA pins..

My program just keeps saying it is failing..

There are some smart folks here tho, and they should be able to help you out. I'll watch the thread & maybe learn something for the 18F2525 too..

Tom

[Tom Gonser]

OK.. I got data back on I2C from the 18F2525! Different than the 877, but perhaps some of what I just figured out will help you...

I am using 24LC512 units, I have two chips wired for addressing as follows:

Chip1 - A0=0,A1=0,A2=0
Chip2 - A0=1,A1=0,A2=0

So, the chips can now be called as follows:

Chip1 con %10100000 ' address of chip1
Chip2 con %10100010 ' address of chip2

' -----[ Program Description ]---------------------------------------------
' EEPROM PIN EEPROM PIN NAME PIC PIN MISC
' EEPROM.1 A0
' EEPROM.2 A1
' EEPROM.3 A2
' EEPROM.4 Vss
' EEPROM.5 SDA SDA RC4 DPIN - data
' EEPROM.6 SCL SCL RC3 CPIN - clock
' EEPROM.7 WP
' EEPROM.8 Vcc

Using a setting I THINK is appropriate for this PIC for the I2C master setting from the spec sheets. (I don't know if this is rigth or not, but it seems to be working..)

SSPCON1 = %11011100
SSPCON2 = %01111000

Using RC3, RC4 on the PIC as SLC and SDA:
DPIN var PortC.4 ' I2C data
CPIN var PortC.3 ' I2C clock

My calls then look like this:

I2cwrite DPIN, CPIN, Chip1, address,[$02,$47,STR SSMAX\34],failw

-- and --

I2cread DPIN, CPIN, Chip1, address,[STR SSOUT\36],failr

And it is working well! If you can't get it working, check the MCP sheet for the pic, and look for the register settings for the IC2..

TG

[Melanie]

Like Mulder always said in the X-Files "the answer is out there..."

http://www.picbasic.co.uk/forum/showthread.php?t=587

All you got to do is look for it.

[Archilochus]

Hi Tom,
As far as my small bit of understanding goes - I2Cread/write are software-only routines - and do not use the I2C 'hardware' that is built in to some PICs.
I've been tinkering with I2Cread/write on a 16F628, which has no I2C hardware, and it works fine.

Arch

[Tom Gonser]

When I refer to 'hard wiring' addresses I am talking about the addressing of multiple EEPROMS on the bus. By physically connecting A0, A1, A2 (in the case of the 24LC512 anyway), one sets up an address for each chip so it can be referenced on the I2C bus....

[Archilochus]

Hi Tom,
Yup, I learned about those address bits recently. I was talking about your setting up of the "MASTER SYNCHRONOUS SERIAL PORT (MSSP) MODULE" and its associated SSPCON registers.
Since PBP's I2Cread/write commands are all done in software, you should not need to configure the 'hardware' serial port module - except maybe to turn it off.

Arch

[MikeM17]

I'm new to PIC & this is my 1st post. I know this is an old thread but I had a similar problem with the "255" output & could not find a specific fix. Maybe this update will help out going forward.

Final summary - I changed B0 from "BYTE" to "Word". This allowed correct excecution but I don't know if it was the real cause.

My whining goes here .. after 3 days of data sheets, permutations of the code and troubleshhoting the Lab-X1. (which really did'nt need any)

Detail - The hardware is brand new flawless Lab-X1. The original code is straight from the Lab-X1 included files = i2cx.bas (below) with a 24C32 eeprom. 16f877a

Using MCS+ with ME U2 programmer & ICD:
Define LOADER_USED 1

.................................................. ........

'Define LCD registers and bits
Define LCD_DREG PORTD
Define LCD_DBIT 4
Define LCD_RSREG PORTE
Define LCD_RSBIT 0
Define LCD_EREG PORTE
Define LCD_EBIT 1

SCL var PORTC.3 ' Clock pin
SDA var PORTC.4 ' Data pin

B0 var Byte ' Address <<<<I changed this to "WORD"
B1 var byte ' Data 1
B2 var byte ' Data 2

ADCON1 = 7 ' Set PORTA and PORTE to digital
Low PORTE.2 ' LCD R/W line low (W)
Pause 100 ' Wait for LCD to start up


For B0 = 0 To 15 ' Loop 16 times
B1 = B0 + 100 ' B1 is data for SEEPROM
I2CWRITE SDA,SCL,$A0,B0,[B1] ' Write each location
Pause 10 ' Delay 10ms after each write
Next B0

loop: For B0 = 0 To 15 Step 2 ' Loop 8 times
I2CREAD SDA,SCL,$A0,B0,[B1,B2] ' Read 2 locations in a row
Lcdout $fe,1,#B0,": ",#B1," ",#B2," " ' Display 2 locations
Pause 1000
Next B0

Goto loop

End

...........................

The MCS+ ICD shows that variables B1 & B2 increment properly but when the program goes from this line:

I2CREAD SDA,SCL,$A0,B0,[B1,B2] ' Read 2 locations in a row

to this line:

Lcdout $fe,1,#B0,": ",#B1," ",#B2," " ' Display 2 locations

then both B1 & B2 go to the 255 value.

The data sheet for the eeprom states that it uses a "byte" size variable.
The MELAb code defines the variable properly.

As a newbie I get to say for at least a couple more posts "I don't get it" why the change from the I2Cread line to the LCDOUT line would change the variable to 255.

My complements to MELABS MCS+ for a nice ICD combo.

[mister_e]

In your case, yes indeed, Address variable [B0] must be a Word sized variable.

let's see if we open and read the 24c32 datasheet...
http://www.atmel.com/dyn/resources/prod_documents/doc0336.pdf

PDF page 11, figure 2, it really show you need to send the device Address/Control Byte ($A0), then Word Address (2 bytes-1 Word), and finally the data.

[MikeM17]

OK Steve, thx. ... Lesson learned:
"Speed reading the data sheet 12 times does not equal slooowww reading it once." Maybe I'll use that under my signature.

[Bill Legge]

This thread has been very helpful but the PBP manusl seems misleading:

1. It would only take a line to explain that the Control byte always starts 1010.

2. In the examples, the Control byte for the smaller chips is given as %1010xxx0 and x means 'don't care.' It does matter is your chip has a hard wired address. e.g

A2 to G, A1 to G, A0 to VCC - xxx becomes 001.
A2 to VCC, A1 to G, A0 to G - xxx becomes 100 etc.

3. Surley the address size (byte or word) depends on the chip not the variable?

It took me 2.5 days to arrive at my present 'thin' understanding - this seems par for the course with this command. If I still have some of the above wrong - please reply.

Bill Legge

[Melanie]

1. It would only take a line to explain that the Control byte always starts 1010

Then the line would be wrong. The Control Byte depends on the device you're talking to, different devices from different manufacturers can and do have different Control Codes. Refer to the DATASHEET of the device you're playing with.



In the examples, the Control byte for the smaller chips is given as %1010xxx0 and x means 'don't care.' It does matter is your chip has a hard wired address. e.g

A2 to G, A1 to G, A0 to VCC - xxx becomes 001.
A2 to VCC, A1 to G, A0 to G - xxx becomes 100 etc.

In the PBP Manual 'xxx' is only given as 'don't care' for the 24LC01B and 24LC02B. It's NOT listed as 'xxx' for any others in the table. If you refer to the DATASHEET of those devices you will discover those Address Lines DON'T WORK. This is NOT the case for other (larger) devices and in those cases 'xxx' correctly isn't listed. The PBP manual is concise and correct in this respect. Once again if you missed it from point 1 above... Refer to the DATASHEET of the device you're playing with. The only thing that should be remembered is that the CONTROL BYTE should be a VARIABLE and NOT a Constant.



3. Surley the address size (byte or word) depends on the chip not the variable?

No, the PBP Manual states that you should use a WORD if addressing a device that requires a WORD, and a BYTE for any device that requires a BYTE. If you use a CONSTANT, and that CONSTANT has a value which is less than 256 (ie it fits into a BYTE size), the compiler may allocate you a BYTE as that CONSTANT, which if you then go and use that BYTE in a situation where a WORD is expected, you're going to wreck your day.



It took me 2.5 days to arrive at my present 'thin' understanding - this seems par for the course with this command.

Actually, other than stating the Control Byte should be a variable I2CREAD & I2CWRITE is well documented.



If I still have some of the above wrong - please reply.

See above

So, in summary... READ the PBP MANUAL... READ the device DATASHEETS. You're only going to have yourself to blame if you don't follow the rules.

[Bill Legge]

Melanie,

Thanks very much for taking the time to reply in full. I gone back over by code, taking care of the CON/VAR business and all is now working well.

Here in the SW of West Australia it's a sweltering 30 degrees (according to my DS1830/PIC 16F84A) - I'm off for a swim in the dam.

Regards

Bill Legge