I ran into the same problem about a year ago. In fact, in reading my
notes it was almost exactly 1 year ago that I finally got it working
completely. I'll try to reconstruct everything for you.

I actually encountered a series of problems which obscured the
solutions pretty effectively. 

When I first installed the code supplied by Microchip it did not save
to or read from the on-board EEProm. Many calls to tech support got me
to someone who was supposed to know how this part works. He eventually
sent me his test code which he claimed proved that the part works.
Unfortunately, his test code was faulty and would never show a
failure. I later pieced together that the person who had originally
written the code was no longer at Microchip and there didn't seem to
be anyone there who knew much about it.

The next problem I ran into occured when I tried to use the MPLAB
ICE2000 to try to locate the problem. Completely undocumented is the
fact that the EEprom is offchip in the emulator and therefor uses a
different port than the actual chip. In order to make the emulator
even attempt to access the EEProm I added this code to the beginning
of FLASH51X.asm:

#ifdef  EMULATED
I2C_PORT    EQU     5   ; Port A control register, used for I2C
SCL         EQU     01H         ; EEPROM Clock, SCL (I/O bit 7)
SDA         EQU     00H         ; EEPROM Data,  SDA (I/O bit 6)
#else
I2C_PORT    EQU     GPIO   ; Port B control register, used for I2C
SCL         EQU     07H         ; EEPROM Clock, SCL (I/O bit 7)
SDA         EQU     06H         ; EEPROM Data,  SDA (I/O bit 6)
#endif

Getting this information was like pulling teeth.

After getting the emulator working, I was able to look at the timing
by hooking a scope to the EEProm on the emulator pod. You can also
accomplish this just as well by using an external 24LC00. I did find
that the timing was not correct in the Microchip code although I don't
remember all the details there. It's easy to see with a scope.

After fixing the timing, I was able to get the code working on the
emulator. This working version was incorporated into my code so that
the PIC would store the state of a switch when pressed and would read
the EEProm on power-up to set the switch to the correct state. The way
I had the code written at this time, the chip would attempt to read
the EEProm five times before failing. What I didn't realize until
later was that it would always fail the first time, but read correctly
the second time. I burned a windowed part next and found that the code
still functioned properly.

I next burned this code into an SO-8 OTP part which is my production
part. The code no longer functioned! I finally stumbled onto the
solution of generating a valid stop bit at start-up. This seems to
indicate that there is a difference between the windowed part and the
SO-8 part that manifests itself as different initialization
requirements. This finally solved the problems and we have been in
production with this part for about a year with no problems. 

To my knowledge, Microchip has never corrected the code on the
website, even though they are aware that people have been having
problems with it. Tech support in Arizona showed very little interest
in helping me out, probably because I design industrial equipment that
is produced in the 100's and 1000's instead of the 100,000's. I do
know that Microchip's faulty code and lack of documentation cost me
about three weeks on my project that I didn't have to spend. I did
hear last fall that there is someone there now who is supposed to be
an I2C expert. The name I was given was Dan Butler.


I hope this helps you out some.

John Burkhardt

jrburk@attglobal.net



On Tue, 16 May 2000 10:28:19 -0500, you wrote:

>Hello PICsters.
>
>I'm currently working on a design that saves parameters into EEPROM of a
>12CE519 upon powerdown.  I originally expected this to be easy; after all,
>Microchip supplies routines to access the internal I2C 24LC00 that's on chip
>(but off die) on the 12CEXXX parts.
>
>However, it's not working.  Since the EEPROM is internal, I can't even monitor
>(a la logic analyzer or 'scope) the access lines.
>
>Perusing the PICLIST archives, I've found an occasional reference to a bug
>in the Microchip routines, and even reference to a solution posted to Tjaart's
>(now non-existant) web site.
>
>Does anyone know the trick to saving and recalling bytes from the internal
>EEPROM on the 12CEXXX chips?  I do know of the obvious type (misspelled
>memory location).
>
>Has anyone gotten the EEPROM routines to work correctly?
>
>Thanks,
>John