TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: Marttyn en 06 de Mayo de 2016, 09:02:51
-
Hola!
Tengo varios proyectos para diferentes aplicaciones que usan el PIC 12F1840 (incluso alguno mas antiguo que usaba el PIC 12F683) y este guarda unos valores de configuracion en la EEPROM interna del PIC.
En un inicio "normal" se leen los valores de la EEPROM, pero como el programa no puede funcionar sin esos valores, si los valores no entran dentro del rango de lo esperado, entonces se borran los anteriores y se almacenan los valores por defecto.
Estos valores tambien se pueden modificar manteniendo un pulsador antes de alimentar el circuito, y antes del loop principal, si se lee que el pulsador esta presionado, entonces entra en modo configuracion y se pueden almacenar nuevos valores en la EEPROM.
Cada tanto me encuentro que el programa tiene los valores por defecto y si bien todo funciona, hay que configurarlo nuevamente para adaptarlo a la aplicacion concreta, ya que los valores por defecto no son operativos.
Mis sospechas:
-Estos circuitos estan pensados para usar a pilas o baterias recargables, por lo que si estas estan muy descargadas podrian llevar al micro a una situacion de no tener alimentacion suficiente para funcionar correctamente, por lo que en algun funcionamiento erratico podria saltar el programa a la posicion de poner los valores por defecto de la EEPROM.
-Muchos circuitos usan servomotores, que pueden producir picos de voltaje y podria ocurrir lo mismo que en el caso anterior.
Soluciones:
-Hago una triple comprobacion antes de borrar la memoria, para estar seguro de que es algo que se esta haciendo deliberadamente.
-El primer valor de la EEPROM lo uso como "proteccion contra escrituras". Si el valor no es uno determinado, entonces la rutina que borra/escribe la eeprom no puede continuar. El valor este lo modifico desde otra posicion del programa ya que si lo hago en la misma rutina, y el programa salta entoces es como si no hubiera hecho nada.
-Configurar el Brownout Reset para que el micro no funcione por debajo de cierto voltaje.
Ha funcionado?
Pues en parte... Ya no ocurre tan a menudo, pero sigue ocurriendo :(
Si el problema es que el programa salta, da igual cuantas comprobaciones ponga... ya que si salta justo al pundo de borrar la EEPROM no se me ocurre que poder hacer.
Por otro lado, me parece raro, pero no se me ocurren ni mas motivos ni mas soluciones.
A algien le ha pasado algo asi? Alguna solucion?
Lamento no poder poner el codigo, ya que son diferentes proyectos, y ademas con codigos largos. Si hace falta puedo poner algun fragmento de codigo que pueda ser relevante.
Un saludo!
-
Hola Martty.
El error puede estar durante el funcionamiento NORMAL del programa y del circuito. Con normal me refiero a que toda la electrónica y tensión de la fuente anda perfecto y no recibe ruido eléctrico.
Tu mencionaste que el circuito va modificando los valores de configuración según valla trabajando. Pues bien, debe haber un evento que haga modificar la configuración y lleva al PIC a cargar un valor que no es el recomendado.
Una solución a esto, es que pongas una rutina de "control de calidad", en el que asegure que los valores a modificar estén dentro del rango correcto; así, en un inicio, el pic no tenga que modificar los valores de la EEPROM a valores por defectos (*); y puedes guardar un valor en la EEPROM con el rango superior o inferior mas cercano. Por ejemplo, tu rango de valores van de 0Ah a 1Ah. El evento quiere guardar el valor 08h; por lo tanto, la rutina de control evitaría guardar dicho valor y guardaría en su defecto, el valor 0Ah.
Lamento que hablo en forma general, pero no se que es esa configuración, que eventos pueden modificar dichos valores, y cuales son los rangos necesarios para un correcto funcionamiento.
(*) En modo depuración, puedes hacer detener el programa y que el PIC te avise que cosa generó un error y con qué valor iba a grabar la eeprom. Esto te podrá ayudar a encontrar que cosa puede estar generando un error.
Cuando el PIC esté en su funcionamiento definitivo, si tienes los medios, puedes generar un LOG DE ERROR, así en futuras consultas o mantenimiento, puedes saber que cosas están fallando.
-
Gracias Leon por tus consejos!
Lo de generar un log de error lo veo complicado, ya que habria que incluirlo en todos los circuitos a nivel hardware y software, y sinceramente no sabria ni por donde empezar :oops:
Con respecto a mi programa, el funcionamiento es el siguiente:
-inicializo PIC
-Si se esta presionando un boton entro en modo configuracion, sino en modo normal
En modo CONFIGURACION:
-puedo modificar los valores de la EEPROM, los valores que se graban ya se han comprobado que sean validos. Una vez terminado reinicio el PIC
En modo NORMAL:
-Leo EEPROM
-Si los valores son validos los asigno a unas variables para que el programa trabaje con ellas
-Si no son validos borro EEPROM y grabo valores por defecto
El programa NO TOCA PARA NADA los valores de EEPROM, tan solo se leen al inicio y se le asignan a variables.
Los valores solo se modifican por el usuario en caso de entrar en la configuracion.
Solo hay 2 momentos en donde puede ocurrir un error (en un transcurso normal del programa):
-Cuando compruebo el boton al inicio. En caso de que la comprobacion no sea correcta entraria en modo configuracion, donde si se puede modificar los valores de EEPROM
-Cuando se lee la EEPROM, si el primer valor de la EEPROM no es uno determinado (como una llave) considera que la EEPROM esta vacia o mal configurada y reescribe los valores por defecto.
Mi principal sospecha es que son los picos de voltaje, por que tengo un circuito del que habre vendido 200uds quizas y nunca he tenido ningun problema. Este circuito utiliza el mismo PIC, e igualmente guarda los datos en EEPROM, pero su alimentacion proviene directamente de un iPod, bien regulada y sin servos o consumos elevados que vayan a generar ningun pico.
Donde si se me borra la EEPROM es en los circuitos que llevan servomotores. :5]
Creo que lo que tengo que hacer es una "caja fuerte" para la EEPROM. Como un sistema de seguridad que si no se activan los (varios) sistemas de seguridad pertinentes entonces no se puede acceder a modificar la EEPROM...
-
Si solo te pasa con los servomotores, entonces es ruido eléctrico.
¿Usan fuentes separadas? Si usan la misma fuente, lo que puedes hacer es separarla; y para activarla usar optoacopladores; de esta manera, se logra separar el ruido que puede venir por la fuente.
-
Si, algunos circuitos puedo separar la fuente, pero otros no.
Quizas sea mejor encontrar una proteccion por software, es mas barato y rapidamente adaptable.
Seguire pensando.
-
Quizas sea mejor encontrar una proteccion por software, es mas barato y rapidamente adaptable.
A mi no se me ocurre ninguna, por que el problema persiste, trata de ponerle mas capacitores entre Vcc y GND cerca del micro, tal ves uno de tantalio, y de distintos valores ceramicos. O la empeoras o la mejoras :P
-
A mi no se me ocurre ninguna, por que el problema persiste, trata de ponerle mas capacitores entre Vcc y GND cerca del micro, tal ves uno de tantalio, y de distintos valores ceramicos. O la empeoras o la mejoras :P
Jeje, le metere algun condensador mas y seguire pensadon una proteccion por software. Me gusta el desafio de crear una proteccion para la eeprom :)
-
Es que la unica proteccion que se me ocurre es depender de algun bit (flag) de un registro en RAM. Para saber si poder grabar o no.
Me refiero al comienzo ponerlo en 1 luego de verificar la EEPROM y antes de grabar CADA BYTE ponerlo en 0. Al final de la rutina de EEPROM ponerlo en 1 de nuevo. ( Rutina que graba 1 solo numero) es decir terminas poniendo a 0 luego para cada numero.
Esto podria evitar el que se grabe por que "salto" el codigo. O en el peor caso, solo afectaria a 1 solo campo. Y no todos. Esto tambien implica que la rutina de ponerlos a default deberian de solo modificar el byte problematico y no los demas ( o un grupo y no todos )
Tambien es depender demasiado de la integridad de los datos de la RAM.
Ahora si la modificacion de la EEPROM ocurre por un ruido introducido por Vdd/Vss, hay otro problema. Y ya aca me cuestionaria realmente si la RAM es correcta tambien. Lo cual no podes tener una certeza al igual que la EEPROM. Por eso mismo una proteccion por Soft no veia posible.
Vi una placa que me trajeron que va en un auto, y solo posee una inductancia en la entrada ( 6 vueltas sobre un toroide pequeño ) en la alimentacion + capacitores de la fuente. Luego en el PIC 1 capacitor ceramico de .1uf y luego uno de tantalio ( este fue agregado, soldado por debajo ) de 6uF, toda la proteccion :P, y usa la EEPROM para su programacion.
-------------------
Sigamos pensando nuevamente en el "salto" de programa.
La solucion que di antes queda inutilizada al saltar a la rutina que la graba, hagamos algo mas complejo, antes de la rutina de grabar Toda la EEPROM ademas corroboramos que existan 2 bytes en cierto orden en la RAM ( algo parecido al 0x55 y 0xAA ) Si no estan no graba. Pero aun asi el "salto" puede llevarlo a otra parte donde se ponen esos valores y se le da a grabar. Seguimos con las misma. Lo va a hacer mas dificil, pero no va a solucionar el tema.
Resumen comparacion con algo en la RAM no se puede, por que el salto puede coincidir con las instrucciones de seteo.
-------------------
¿Es realmente un "salto" ?
Si tenes el WDT podes masomenos saberlo, De todas las direcciones de memoria viene a caer JUSTO en la EEPROM y encima varias veces seguidas?. Si ocurre muchas veces y suponemos que el salto es aleatorio, deberian haber saltos de software por muchos lados y no solo en la rutina de la EEPROM. Podrias poner el WDT, y leer los bits de reset para determinar si es que ocurre con el WDT, deberias tener reset por WDT como loco Si realmente fuera un salto de software. Ya que como decia si es aleatorio y suerte que caiga en la EEPROM entonces deberia haber muchos mas saltos que ocurran en partes sin ocupar de la flash.
Otra cosa, si el ruido afectara al PC, por que no afecta a todos los demas registros/RAM, etc. Y nuevamente estamos ante la posibilidad que se modifiquen miles de cosas pero solo se hace una siempre.. Que sumado a lo anterior parece poco probable lo del salto ( aun asi si fuera mas "vulnerable" el PC que lo demas )
Al menos es lo que pienso. Yo opino igual que Leon, para mi es un ruido externo por la alimentacion. Choque en la alimentacion general del micro + capacidad bien cerca de los pines
-
Muchas gracias Killer por tu detallada respuesta!
Me ha hecho pensar cuando dices que el ruido deberia afectar tambien a los demas registros y a la RAM.
Al iniciar el micro, comprueba que en la EEPROM haya un valor concreto (similar a 0x55 0xAA), y si no lo hay asume que no hay valores o son erroneos, por lo que sobreescribe todo con valores por defecto. Quizas aqui este el problema. Quizas la alimentacion del micro aun no esta estable cuando se lee la eeprom, ya que al alimentar tambien el servo da un pequeño tiron de alimentacion. Si este valor no se lee correctamente es cuando se va todo a la mier**.
Probare poner algunos delays al inicio para que estabilice todo antes de leer.
-
Yo venddo uno parecido y nunca se me borro la memoria
-
Que tal Marttyn, aunque el tema es muy viejo, me esta sucediendo algo muy similar a lo tuyo y quisiera preguntarte si pudiste darle solucion.
Mi problema es muy concretamente la posición 0, de la memoria eeprom interna, cada determinado tiempo me cambia ese valor, siempre a cero (0).
No lo hacen todas las tarjetas de ese modelo, pero si que lo hace, a veces, solo regrabando el dato, ya no sucedía nuevamente, pero en otros casos eso no lo solucionaba.
Me gustaria saber como puedo evitar o disminuir la probabilidad de que suceda esto, o si les ha pasado como lo han solventado.
El PIC que uso es el PIC18F46K22
Saludos y muchisimas gracias
-
estas SEGURO que no hay de vez en cunado un usuario, o un empleado o alguien que "toque "?¡?¡
pero SEGURO ???
dices que si al iniciar si esta manteido pulsado entra en modo programacion y ..... imagina que algun "niño" hace eso , y si tienes una pantalla o leds que titilan eso se pone lindo.....
estando en ese modo dime:
se puede provocar por hacer tonterias que pase lo que dices '?
-
Hola!
Tengo varios proyectos para diferentes aplicaciones que usan el PIC 12F1840 (incluso alguno mas antiguo que usaba el PIC 12F683) y este guarda unos valores de configuracion en la EEPROM interna del PIC.
En un inicio "normal" se leen los valores de la EEPROM, pero como el programa no puede funcionar sin esos valores, si los valores no entran dentro del rango de lo esperado, entonces se borran los anteriores y se almacenan los valores por defecto.
Estos valores tambien se pueden modificar manteniendo un pulsador antes de alimentar el circuito, y antes del loop principal, si se lee que el pulsador esta presionado, entonces entra en modo configuracion y se pueden almacenar nuevos valores en la EEPROM.
Cada tanto me encuentro que el programa tiene los valores por defecto y si bien todo funciona, hay que configurarlo nuevamente para adaptarlo a la aplicacion concreta, ya que los valores por defecto no son operativos.
Mis sospechas:
-Estos circuitos estan pensados para usar a pilas o baterias recargables, por lo que si estas estan muy descargadas podrian llevar al micro a una situacion de no tener alimentacion suficiente para funcionar correctamente, por lo que en algun funcionamiento erratico podria saltar el programa a la posicion de poner los valores por defecto de la EEPROM.
-Muchos circuitos usan servomotores, que pueden producir picos de voltaje y podria ocurrir lo mismo que en el caso anterior.
Soluciones:
-Hago una triple comprobacion antes de borrar la memoria, para estar seguro de que es algo que se esta haciendo deliberadamente.
-El primer valor de la EEPROM lo uso como "proteccion contra escrituras". Si el valor no es uno determinado, entonces la rutina que borra/escribe la eeprom no puede continuar. El valor este lo modifico desde otra posicion del programa ya que si lo hago en la misma rutina, y el programa salta entoces es como si no hubiera hecho nada.
-Configurar el Brownout Reset para que el micro no funcione por debajo de cierto voltaje.
Ha funcionado?
Pues en parte... Ya no ocurre tan a menudo, pero sigue ocurriendo :(
Si el problema es que el programa salta, da igual cuantas comprobaciones ponga... ya que si salta justo al pundo de borrar la EEPROM no se me ocurre que poder hacer.
Por otro lado, me parece raro, pero no se me ocurren ni mas motivos ni mas soluciones.
A algien le ha pasado algo asi? Alguna solucion?
Lamento no poder poner el codigo, ya que son diferentes proyectos, y ademas con codigos largos. Si hace falta puedo poner algun fragmento de codigo que pueda ser relevante.
Un saludo!
se me ocurre lo siguiente:
tu tienes los valores iniciales, que como dices se graban por defecto si ocurre un problema... y si en vez de eso haces asi:
1 -- valores iniciales, que solo se toman en cuenta la primera vez y tambien solo si activas un "reset oculto" ( que solo tu puedas activar.
2 --- valores ultimos de respaldo que seran estos a donde recurre el micro si hay un problema.
3 --- valores en uso , estos son lso valores que el usuario o tu programa .
funciona asi:
tu pulsas el boton y entras en modo programacion, como haces tu : al mantener pulsado cuando arranca, todo bien, cambias valores, o el mismo micro se ocupa de leer y cambiar, como haces siempre, y esos valores se graban en las direcciones (3) .
PERO A LA VEZ, AL SALIR TAMBIEN SE GRABAN EN OTRAS DIRECCIONES DE RESPALDO ( 2) .
el programa trabaja siempre mirando y usando las direcciones ( y sus contenidos) de (3 ) y si hay un problema, por defecto cargara todo lo de la direccion 2 , que basicamente es el respaldo o sea los valores ultimos...
la otra que puedes hacer es verificar si realmente se te esta borrando la EE, haciendo un programita, imagino que esta la placa ya hecha, y esa placa esta en la calle, donde usuarios, asi que es dificil modificar, seria un problema ese.......
si de verdad se te borra la EE ahi no sirve de nada lo que te dije, el tema es verificar si realmetne se te borra la EE o si algun salame esta jugando con el boton....
-
Gracias por tu respuesta! Ya hace tiempo de este post, y nunca consegui solucionarlo completamente. Cada tanto me llama un cliente diciendo que la placa se le ha desconfigurado sin el haber hecho nada.
No he podido averiguar cual es el problema, ya que a mi no me ha ocurrido nunca en todas las pruebas que he hecho, pero a lo largo de estos años he ido aplicando pequeñas correcciones al codigo que han disminuido los problemas.
Una de esas mejoras ha sido como has dicho, tener un respaldo de los ultimos valores guardados.
A estas alturas he asumido el fallo y me resulta mas rentable explicar a un cliente como reconfigurar el circuito que seguir investigando el tema. Sobre todo cuando el problema no se presenta muy a menudo...
-
Que mal, pense que tal ves habias podido solucionarlo, no se que igual era un bug del compilador CCS, a mi me ocurre de ves en cuando, pero es algo molesto para el cliente tener que estar recargando el valor.
Intentare lo del valor de respaldo, tal ves con ello logre disminuir la incidencia.
Te agradezco mucho por tus sugerencias y experiencia
Saludos.
-
Que mal, pense que tal ves habias podido solucionarlo, no se que igual era un bug del compilador CCS, a mi me ocurre de ves en cuando, pero es algo molesto para el cliente tener que estar recargando el valor.
Intentare lo del valor de respaldo, tal ves con ello logre disminuir la incidencia.
Te agradezco mucho por tus sugerencias y experiencia
Saludos.
Que bueno para mi consuelo saber que no soy el único que me pasa eso.
estoy usando el pic18F4550 desde hace un par de años en este proyecto. son unas maquinas que se vendieron varias hasta el momento. y ahora me encargaron una tanda mas.
En fase de desarrollo tenia ese problema. Tuve dos problemas con la eeprom interna. 1 es ese, esporádicamente la posición 0 de la ram interna se quedaba en 0.
mi programa al inicial pone los valores de diversos parámetros por defecto, Al declarar las variables las pone por defecto, luego llama a la rutina que carga esos valores de la eeprom, mira si los dos valores son 0x55 y 0xaa (lo habitual) y si es correcto carga los valores pisando los de defecto,
pero si el encabezado no es eso, llama a la rutina que graba el seteo y graba todo el bloque por defecto. (esto ocurre con el primer uso después de grabar el pic) después el usuario tendrá que setear cada uno.
El programa apaga las interrupciones globales y toma todos los recaudo, hice lo mas prolijo posible.
Notaba que a veces al iniciar se cargaba los valores por defecto. Pero lo hacia muy esporadicamente, podía pasar muchos encendidos para que falle. en busca de la falla cambie la rutina que graba por otra manual. y ahí pude comprobar que a veces se cambiaba la dirección 0 por 0.
Lo primero que hice fue no usar esa posición, y grabar a partir de la dirección de eeprom 0x20, total estoy grabando una docena de variables, algunas de 16 bits, pero todo no suma ni 20 bytes, mientras que la eeprom es de 256 bytes. sobra espacio. no afecta en nada si grabo todo mas abajo.
Por suerte no tuve mas problemas (tal vez siga el problema, pero como no se usa la posición 0 no me entero)
ni tampoco tuve reportes de los clientes comentando una falla.
También tuve un problema relacionado con la eeprom interna. que en ocasiones una lectura me da 255. y el parámetro se salia de rango. en este caso fui mejorando la rutina de lectura del bloque de parámetros. Como decían mas arriba. termine haciendo dos rutinas complejas te toma todo en cuenta.
si leyó mal re intenta varias veces. y recién después carga el defecto. Con todo esto nunca mas me falló nada ni tuve reportes de clientes.
Lo de tener un juego de seteo de respaldo no se me había ocurrido, es una buena idea.
Tengo un led en la plaqueta que uso para debug, un led que parpadea en condiciones normales. pero si hay un error de lectura el led se queda apagado, y si es de escritura se queda encendido. Nunca me reporto un fallo, pero bueno, esta.
solo se que funciona por que hice pruebas de cambiar valores a mano con el grabador de pic para simular un fallo.
Y algo mas que me paso, y con esto termino. en programas en donde el micro se usa verdaderamente mucho y con variables de 32 bits. y varios llamados a subrutinas, tenia errores raros, es muy largo de explicar (y no quiero a aburrir a todos), pero los errores desaparecían al apagar el PLL interno. o sea, dejo el oscilador con el cristal de 20Mhz sin PLL, todo funciona perfecto. Enciendo el PLL para llevar el clock a 48Mhz, y tengo problemas. esto lo tengo bien comprobado. Pero como es otro proyecto que no esta en uso por el momento, deje el problema archivado.
-
Que mal, pense que tal ves habias podido solucionarlo, no se que igual era un bug del compilador CCS, a mi me ocurre de ves en cuando, pero es algo molesto para el cliente tener que estar recargando el valor.
Intentare lo del valor de respaldo, tal ves con ello logre disminuir la incidencia.
Te agradezco mucho por tus sugerencias y experiencia
Saludos.
Que bueno para mi consuelo saber que no soy el único que me pasa eso.
estoy usando el pic18F4550 desde hace un par de años en este proyecto. son unas maquinas que se vendieron varias hasta el momento. y ahora me encargaron una tanda mas.
En fase de desarrollo tenia ese problema. Tuve dos problemas con la eeprom interna. 1 es ese, esporádicamente la posición 0 de la ram interna se quedaba en 0.
mi programa al inicial pone los valores de diversos parámetros por defecto, Al declarar las variables las pone por defecto, luego llama a la rutina que carga esos valores de la eeprom, mira si los dos valores son 0x55 y 0xaa (lo habitual) y si es correcto carga los valores pisando los de defecto,
pero si el encabezado no es eso, llama a la rutina que graba el seteo y graba todo el bloque por defecto. (esto ocurre con el primer uso después de grabar el pic) después el usuario tendrá que setear cada uno.
El programa apaga las interrupciones globales y toma todos los recaudo, hice lo mas prolijo posible.
Notaba que a veces al iniciar se cargaba los valores por defecto. Pero lo hacia muy esporadicamente, podía pasar muchos encendidos para que falle. en busca de la falla cambie la rutina que graba por otra manual. y ahí pude comprobar que a veces se cambiaba la dirección 0 por 0.
Lo primero que hice fue no usar esa posición, y grabar a partir de la dirección de eeprom 0x20, total estoy grabando una docena de variables, algunas de 16 bits, pero todo no suma ni 20 bytes, mientras que la eeprom es de 256 bytes. sobra espacio. no afecta en nada si grabo todo mas abajo.
Por suerte no tuve mas problemas (tal vez siga el problema, pero como no se usa la posición 0 no me entero)
ni tampoco tuve reportes de los clientes comentando una falla.
También tuve un problema relacionado con la eeprom interna. que en ocasiones una lectura me da 255. y el parámetro se salia de rango. en este caso fui mejorando la rutina de lectura del bloque de parámetros. Como decían mas arriba. termine haciendo dos rutinas complejas te toma todo en cuenta.
si leyó mal re intenta varias veces. y recién después carga el defecto. Con todo esto nunca mas me falló nada ni tuve reportes de clientes.
Lo de tener un juego de seteo de respaldo no se me había ocurrido, es una buena idea.
Tengo un led en la plaqueta que uso para debug, un led que parpadea en condiciones normales. pero si hay un error de lectura el led se queda apagado, y si es de escritura se queda encendido. Nunca me reporto un fallo, pero bueno, esta.
solo se que funciona por que hice pruebas de cambiar valores a mano con el grabador de pic para simular un fallo.
Y algo mas que me paso, y con esto termino. en programas en donde el micro se usa verdaderamente mucho y con variables de 32 bits. y varios llamados a subrutinas, tenia errores raros, es muy largo de explicar (y no quiero a aburrir a todos), pero los errores desaparecían al apagar el PLL interno. o sea, dejo el oscilador con el cristal de 20Mhz sin PLL, todo funciona perfecto. Enciendo el PLL para llevar el clock a 48Mhz, y tengo problemas. esto lo tengo bien comprobado. Pero como es otro proyecto que no esta en uso por el momento, deje el problema archivado.
Tengo unas preguntas.
Suponiendo que tu código está correctamente escrito y tienes un método de verificación de lo que está almacenado en la eeprom (LRC, CRC, Checksum, etc)
1. ¿Tienes habilitado el BOR?
Ante un bajón de voltaje, el CPU del microcontrolador puede seguir operando pero el código puede hacer cosas absurdas como escribir datos erróneos en la eeprom. Habilitado el BOR, mantienes al CPU en reset durante esas caídas y evitar que haga "tonterías"
2. ¿Tienes habilitado el POR?
Si tu código escribe/lee o intenta escribir/leer la eeprom cuando el CPU se energiza. Intentar hacer estas acciones (leer o escribir) cuando VDD aun no está en su valor nominales puede causar que se altere el contenido de dicha memoria, sobre todo sus direcciones iniciales. El POR mantiene al CPU en reset hasta alcanzar un nivel correcto de operación, evitando el problema.
3. ¿Estás trabajando en ambientes de alta temperatura?
Yo tuve este tipo de problemas con otro tipo de microcontrolador, luego de 3 a 4 meses, la eeprom de datos se alteraba, ya que el dispositivo trabajaba en una zona tropical, dentro de una maquinaria que generaba mucho calor.
4. ¿Tu dispositivo está trabajando en zonas de alta frecuencia? Por ejemplo junto a lámparas fluorescentes.
El ruido suele ser otro problema al momento de escribir y leer la eeprom. Utilizar la siguiente clase de filtros es muy bueno para ayudar a reducir el problema: