Interference occuring reading/writting the EEPROM

Status
Not open for further replies.

harshani

Newbie level 3
Joined
Apr 25, 2013
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,301
Hello,
I'm building a counter with LCD using PIC16f876 and I'm writing the counter value after every operation in the EEPROM so I can access the counter value after switching off the device. But when turning on and off the device several times, the EEPROM value get changed. Sometimes I get the correct value but rarely a different value is shown in the display. I tried reading the value in such a condition inside the EEPROM and it also got deviated. Can anybody tell what might cause this problem please??
 

The write operation takes several mS, is it possible you switched the power off part way through a write operation and it never completed? If that is the problem it's difficult to fix as obviously no operation can take place withut power but it may be possible to synchronize the power control with the PIC so it holds the power on for long enough to check a write operation has finished.

Although write operations are locked if VDD is low, after writing to an EPROM location I always change the EEADR registers to point to an unused EEPROM address just in case a power glitch triggers a new write cycle.

Brian.
 

Thanks Brian,
I'm not sure what is exactly happening here but the eeprom value sometimes get either reset(00) or it shows 255(FF) after turning on and off the power supply several times. and can you tell me how to synchronize the power control with the pic, I'm a newbee
 

You can only do it if the PIC itself can control the power, for example if your application has a power button or 'standby' button that lets the software turn the power on and off. If it has that ability, all you have to do when turning off is check the EE staus register to see if a write operation is still in progress and delay the turning off until it says it's safe to do so. If you power switch just kills the supply by disconnecting the source there isn't much you can do. Some things might help though:

1. enable the power-up reset timer timer. This will ensure the PIC has had time to sort it's insides out before releasing the reset line.
2. enable the BOR circuit to protect against out-of-spec supply voltages. These may arise during the switching on and off times.
3. when writing to the EEPROM, check the WRERR bit to ensure the write cycle completed sucessfully. Repeat it if an error is detected.
4. disable interrupts (use GIE) during the EEPROM write cycles in case an interrupt breaks the write unlocking sequence.
5. reserve a 'parking address' in EEPROM which isn't used for anything else and after each write operation, set the EEADR register to the parking address.

Electrically, it is theoretically possible to corrupt the memory if VPP is applied during normal operation although it's highly unlikely. If you don't have one at the moment, add a capacitor (100nF) from VPP to VSS to prevent interference accidentaly putting the PIC in programming mode.

Brian.
 
This post helped me. Thanks Brian.

5. reserve a 'parking address' in EEPROM which isn't used for anything else and after each write operation, set the EEADR register to the parking address.

Brian.
what u mean by parking address..?

Janaranjana
 

Thank you. It worked after enabling the BOR cct.
 

@Janaranjana, I mean an address which isn't used for anything else. For example, if you are using addresses 0 - 0x20 you could use any address 0x21 onwards. The idea is that if a write operation accidentally starts (even though it is extremely unlikely) the address that was written to would not upset the program operation. In extremely critical applications I reserve EEPROM address 0x00 for parking as this is the most likely address to be in the EEADR register when the PIC starts up. So a 'normal' write operation would be:
1. set the address and data
2. do the write unlock routine
3. write to the EEPROM
4. set EEADR to the parking address.

It is only one instruction "clrf EEADR" but could save lots of problems later.

Brian.
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…