PIC reads 0xFF from EEPROM

[Pete_UK]

Hello all,

Not logged onto the forum for a long while, but I remember how helpful everyone is with PIC problems... I have another one which is a bit perplexing.

I'm writing a program that writes a single byte of data to an external EEPROM (ATMEL 24C128B) from a 16F876A micrcontroller using I2C. I've been using this document from Microchip as a guide and it's been pretty good up to now. I've not been copying the code exactly, but taking the general structure and implementing it myself to understand the concepts.

When I have written a byte to the EEPROM I immediately read it (there is an ACK loop in the code to test whether the EEPROM is busy) and then send the result back to Hyperterminal using code that I know definitely works and use alot in other projects.

The problem I'm having is that the value 0xFF is always returned. I'm not sure whether this is a read or write problem, as the datasheet for the EEPROM does not state what the default value of each memory location is and I suspect that I could be reading the default value. I've confirmed that the chip is wired up correctly by illuminating an LED once the whole program has completed (write EEPROM, read EEPROM, transmit data byte, light LED), as the program would get stuck in the loops that check for ACK signals.

The code of my program is attached and I hope it's legible. I appreciate any help as I've been through the code a few times now and I think I'm overlooking something obvious.

Thanks again,

Pete

 

[ericgibbs]

hi Pete,

Your code.

movlw    b'101000001'            '[COLOR=Red]9 bits![/COLOR]
        movwf    SSPBUF                ;Transmit control message to EEPROM (read mode)
        call    ssptest
        call    acknowtest

 

[Ian Rogers]

There needs to be at least a 5ms delay after the write command before you read it back.. Place a delay at the end of the write routine before you return.

 

[Pete_UK]

Hi Eric and Ian,

Thanks for your suggestions and corrections. I've implemented them both but it seems to have no effect (although now I know there was atleast more than one bug!)

I've been thinking about whether it could be the way I have my circuit configured. I'm using two 4K7Ohm resistors on my SDA and SCL lines, which is all constructed on a breadboard using wires. Could this be affecting the signal waveform adversly?

Pete

 

[ericgibbs]

Hi Eric and Ian,

Thanks for your suggestions and corrections. I've implemented them both but it seems to have no effect (although now I know there was atleast more than one bug!)

I've been thinking about whether it could be the way I have my circuit configured. I'm using two 4K7Ohm resistors on my SDA and SCL lines, which is all constructed on a breadboard using wires. Could this be affecting the signal waveform adversly?

Pete

hi Pete,
I assume you have WP tied to 0V and the Addr lines correctly connected.???

 

[Pete_UK]

Yeh, I've tied all three of the address inputs and WP to 0v. One of my theories is concerned with this part of the code:

				bsf		STATUS,RP0	;Select Bank 1

		btfsc	SSPCON2,ACKSTAT		;Check to see if EEPROM is writing
		goto	I2Cread				;Return back to I2Cread if it is busy

				bcf		STATUS,RP0	;Select Bank 0

It polls the ACKSTAT bit to check if the EEPROM is busy. Is it possible to have a 'goto' instruction to a point in the program that isn't in the same bank?

 

[Nigel Goodwin]

Yeh, I've tied all three of the address inputs and WP to 0v. One of my theories is concerned with this part of the code:

				bsf		STATUS,RP0	;Select Bank 1

		btfsc	SSPCON2,ACKSTAT		;Check to see if EEPROM is writing
		goto	I2Cread				;Return back to I2Cread if it is busy

				bcf		STATUS,RP0	;Select Bank 0

It polls the ACKSTAT bit to check if the EEPROM is busy. Is it possible to have a 'goto' instruction to a point in the program that isn't in the same bank?

Banks don't affect program flow, banks are only for GPR and SPR memory, which is entirely seperate to program memory.

 

[Mr RB]

The programmer may be writing all the EEPROM locations to 0xFF (erased) every time you program the PIC. I'm not sure if that is related but you should check that out too.

 

[Nigel Goodwin]

The programmer may be writing all the EEPROM locations to 0xFF (erased) every time you program the PIC. I'm not sure if that is related but you should check that out too.

The programmer shouldn't have any connection the EEPROM, it's an external I2C device, not the internal data EEPROM.

 

[Pete_UK]

Fixed! I had forgotten to check whether the RSEN signal had completed in the read routine. I think without it the program would charge on without the EEPROM being ready. Thanks for all your suggestions. What a great forum!

 

[Ian Rogers]

Also pullups on the SDA and SCL lines

 

[Mr RB]

The programmer shouldn't have any connection the EEPROM, it's an external I2C device, not the internal data EEPROM.

Whoops! :Embarassment:

That was a definite case of "me talked too much and listened too little".