eeprom never returns an ack

[hate]

Hi;

My problem is the 24c512 eeprom chip I'm using, never returns an ack! I can read and even write the chip but cannot get an ack! So the pic16f877 I'm using stays forever in the 'while' loop below!

[treitmey]

why are you not using the driver given to you?
C:\Program Files\PICC\Drivers\24512.C

[hate]

That's allready the driver I'm using with only a minor change with the while loop:

[ckielstra]

Your change is not functionaly the same as the original. For example, if the call to i2c_start returns an error code, you will still continue and hence loop forever.

What happens when you revert to the original?

[Ttelmah]

Actually, I have to disagree. The functionality is the same.
The first time into the loop, ther will be a start, and then a write, and then a test for NACK. It'll then test for ACK, and loop if this is not seen. This is exactly what the original code does.
I have seen problems with certain chips, and the hardware I2C, when sending repeated starts (which this code relies on). I found it to only work properly, if instead of sending a repeated start, I added a stop, and tried again. Try adding an I2C_STOP, and see if it starts working. If so, the original code would also have the same problem, but would work, because it is using software I2C, which appears not to have this fault.

Best Wishes

[SLo]

I observed the same problem and my solution was to just wait 5mS as this is the longest specified write time. Not as efficient, but better than being stuck in the loop!
I will however try Ttelmahs fix as this may prove faster.

My function:

[hate]

Hi;

I had tried SLo's suggestion but it hadn't worked. But Ttelmah's solution works, I added the' i2c_stop();' and everything works in hardware mode. Thnx all for your time!

Regards...

[gokuden]

i have the same problem. Where i have to add i2c_stop();? on library? where? im test it on proteus! i changed the memory for a 25lc256 and now its`n sutck in the infinite while but, if a write a number "5" in the address "5". and i read the same address, it return me a 255, no a 5! i dont know what to do now!

void write_ext_eeprom(long int address, BYTE data)
{
short int status;
i2c_start();
i2c_write(0xa0);
i2c_write(address>>8);
i2c_write(address);
i2c_write(data);
i2c_stop();
delay_ms(5);
i2c_start();
status=i2c_write(0xa0);
while(status==1)
{
i2c_start();
status=i2c_write(0xa0);
}
}

[hate]

Here is where I added 'i2c_stop();':

[SLo]

I tried Ttelmahs fix of including the I2C_Stop() and it worked a treat.

Out of interest, I added code to read the timer at the start & end of the write and compared the time taken using the delay_ms(5) and the loop waiting for ack. I appreciate that this may vary for other hardware, but out of interest I noted that the loop for ack code executed about 1.1mS faster than the dumb delay. Clearly a worthwhile saving.

Thanks Ttelmah.

[Ttelmah]

It might be worth making a 'note' of what chips need this fix. I posted, because I had met exactly this problem, and a friend had spent a lot of time and effort working out what on earth was happening. The same code without stops, worked fine on some chips, while the 'soft' I2C also works fine. I'm not sure if the problem is with particular PIC's, or particular EEPROM's. However at least it is a fix, and as said, it does save significant time over 'dumb' waiting...

Best Wishes

[gokuden]

hi. a have a problem with the writting process. I can record it only once. When I record it for the second time and I read the memory, it is only the first data