PIC Microcontoller Memory Method

Internal EEPROM access on 12CExxx devices

John Burkhardt says

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.

Bao zeng Zhang of ShangHaiJiaoTongUniversity Says: " Thanks a million " +