[SOLVED] Internal EEPROM memory of PIC18F4550 Microcontroller issue

[Aussie Susan]

Be careful when you write the two values to the EECON2 register to perform the unlocking when you are writing in C. It is better to write this as in-line assembler so that any compiler optimisations or other compiler generated code does not stop these two instructions being executed by the CPU consecutively.
Even better, as you are using the XC8 compiler, use the 'eeprom_write' and 'eeprom_read' library functions (see section 5.5.5.3 in the XC8 User Guide).
In your previous replies, you mention that this works after a minute but now immediately. However your code will always immediately write to then read from the EEPROM and do into an infinite loop. Where does the "after a minute" come in to operation?
Also the first thing you do is to write to the EEPROM so how can you tell that it is not holding the values across a power down?
In short, the code you have presented does not match the symptoms you have described.
Susan

 

[bluelasers]

This sounds like the behavior of RAM not EEPROM. I am also curious if the EEPROM is actually getting data. I know that there is some funny unlock sequence for it accept writes as mentioned earlier. However I am not sure why that would cause it to magically record and return the correct values after a certain amount of time but not write it to memory. I mean its possible its cached, but if I remember correctly that is not how it is implemented. Also the correct value would be returned immediately or no more than the EEPROM page delay. Part of me says bad chip, but that does not sound likely either.

How do you know the data is right? How do you know that the data from the previous run is persisting a power cycle? (You have to suspend writes to test this!) How large is the window before the data gets overwritten?

Can you burn into the EEPROM a string like "Hello World!" with one program. Then try to read it and see if you can see it? Suspend all the other logic so that this is the only thing using the EEPROM in both programs.

 

[desgin]

This sounds like the behavior of RAM not EEPROM. I am also curious if the EEPROM is actually getting data. I know that there is some funny unlock sequence for it accept writes as mentioned earlier. However I am not sure why that would cause it to magically record and return the correct values after a certain amount of time but not write it to memory. I mean its possible its cached, but if I remember correctly that is not how it is implemented. Also the correct value would be returned immediately or no more than the EEPROM page delay. Part of me says bad chip, but that does not sound likely either.

How do you know the data is right? How do you know that the data from the previous run is persisting a power cycle? (You have to suspend writes to test this!) How large is the window before the data gets overwritten?

Can you burn into the EEPROM a string like "Hello World!" with one program. Then try to read it and see if you can see it? Suspend all the other logic so that this is the only thing using the EEPROM in both programs.

Ya, thanks for the reply.
Hello Word string working perfectly alright.
Reading and writing working perfect, only issue happening when i remove power supply and again connect it.

 

[KlausST]

Hi,

only issue happening when i remove power supply and again connect it.

A bit more detailed informations, please.

Klaus