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.
