datos en eeprom en mega alterados

Buenas, a ver si es posible lo que me ha pasado y los motivos. No sabia si ponerlo en hard por ser memoria fisica el chip o aqui, al tratarse de datos. Tengo un mega con más de 1000lineas de codigo (el control del grupo de presion) que cada dia guarda en epp los datos de funcionamiento, minutos y arrancadas, o bien al mantener pulsadomás de 10 segundos un pulsador, de forma manual. Esto funciona y ha funcionado. Hace 4 semanas cambié todo el hard e intenté cargar el nuevo sketch, previo guardado de datos. Donde está instalado este montaje, me llevo un portatil de bastantes años y compilar y cargar dura sobre medio minuto, hasta aquí no hay problemas, me espero y problema finalizado.Hace esas 4 semanas que me salieron errores al cargar, que el sketch era demasiado grande, avr no sé qué mas, y no les presté importancia al tratarse de un portatil antiguo, lo que hice fue dejar otro ya programado y traerme el que tenia los datos almacenados, aqui con el mismo portatil, ya para ver qué pasaba, va y me lo carga sin problemas (tras 30 segundos). Como en estas cosas hya fantasmas, no le dí más vueltas, luego intenté un cambio y otra vez errores, y los problemas solo los tenia cuando estaba el portatil con el cargador, solo con bateria perfecto. Vale, sabiendo esto pues facil solucion tiene. Ayer ya instalé estemodulo del mega y me salieron todos los datos almacenados modificados, tanto minutos de marcha como datos de preajuste de arrancada y paro de la bomba. Borré los datos y todo de cero y ya está, en este caso no hay problema. Lo que me gustaria saber: ¿Puede ser que al haber hecho varios intentos de subir el sketch, le haya afectado a la epp de los datos? ¿el mega u otro arduino, usa la misma mamoria física (chip) para todo? gracias

No debería haber problemas, el único fallo que podría ocurrir es que que hayas cargado un sketch de pruebas en lugar del que ya tenías en operación y en el cual, hayas cambiado por alguna razón el orden de almacenamiento en la EEPROM.

Quizás por allí persista un error que no has eliminado y por eso ahora que revisas, salten horrores por todos lados.

De otra forma no es posible que pierdas la secuencia de almacenamiento en la EEPROM.

PD: a menos que seas tan escrupuloso en guardar a cada segundo todo. ¿Has pensado en una FRAM de 32 Kb o de 8 Kb como las de adafruit?, tienen la friolera de 10,000,000,000,000 ciclos de escritura/lectura

gracias, pero en 9 años si queda mundo, espero poder jubilarme, y la eprom puede llegar a esos 9 años y más y quien venga detras, que se espabile xD los datos que se guardan no son en absoluto imprescindibles,lleva en servicio 11 años y no tenia ni un triste cuentahoras, así que si los datos se pierden, no pasa nada, es más por curiosidad que otra cosa que se muestran el unico sketch de pruebas era el de poner en hora el reloj, tal mega quitado no lo usé para nada más, aparte que ayer puse el portatil al cargar y con alimentador otra vez error al subir, y solo con este, ya que el ino del reloj con el portatil conectado a 220 sube sin problemas,y sé que teoricamente no tiene nada que ver, pero el portatil no opina igual.

Se me ocurre preguntarte por los errores. A veces dejamos pasar los warnings, a mi no me gusta que un código me de warnings. Si me los da es porque programo mal, y antes que alguien piense lo contrario se que programo mal. El 80% de las veces tengo warnings pero lucho y lucho e investigo para quitarlos. Ejemplo: si alguien define una variable como int y luego el elemento para comparar es un unsigned int recibirá un warning o advertencia de que en algún momento la comparación no será lo que se espera. Eso parece una tontería pero dentro del campo de números positivos todo esta bien pero al comparar un negativo int con un no positivo unsigned int que resulta? Bueno.. esto como decimos en Argentina sanateando o traducido imaginando cosas (tus fantasmas tal vez?) pero que tal empezar por ahí?

gracias por responder. Los errores no eran provocados por el sketch, ya que aquí, encima de la mesa con una torre de ±2 años carga superrapido y sin problemas, y funcionando en pruebas, todo de forma correcta, y este mismo .ino copiado a un lapiz usb y “pegado” al portatil, y SOLO cuando está alimentado con red en vez de con su bateria, es cuando me daba errores, el más llamativo que el sketch era demasiado grande, y tal cual estaba en el portatil, ya con bateria, cargado a la primera, exactamente el mismo archivo. Ni idea de porqué con red me da errores, lo que haré será el lunes probarlo otra vez con el portatil (el mega de recambio) conectado a red eléctrica, y pondré los errores que da.
saludos

Y no se te olvide capturar las advertencias.

Intenta no actualizar el IDE de arduino cada vez que sale, he visto que esa practica no es bien recibida por librerías que no se actualizan en la misma frecuencia, y saltan advertencias o errores.

PD: los IDE´s que considero mis favoritos son el 1.5.6-r2 y el 1.6.11; aunque algunas librerías no funcionan entre ambas versiones, las que uso para las pantallas FT8XX/ILI9341 no han sido mayormente afectadas; pero tengo soporte para placas nuevas como el Teensy 3.6 y placas maduras como el Teensy 3.2/UNO/MEGA/Due

Exacto adhiero a lo que dice TFTLCDCyg (algún dia dime si quieres por MP el porque este nick, me intriga jaja?). Entre mis prácticas tambien estoy agregando la versión de ide con la que todo funcionaba. No la guardo porque esta en el sitio de arduino pero estoy totalmente de acuerdo que no debe complicarse uno con las versiones. SI algo funcionaba y ahora no.. volver atras y usar esa versión. Anotar

/* Version de IDE = 1.6.5 
   librerías          : nombre.rar
   tinygps Version    : 3.4 web = http://www.github.com/xxxxxxxxxxxxx
 */

Bien, acabo de probarlo en la "oficina central", donde tengo tooooooodo el tiempo del mundo, y por supuesto, carga a la perfección, la ultima y las anteriores versiones que ya tenia en el portatil. Cuando voy donde está instalado, voy por esto y principalmente 40 cosas más de la planta, y me falta tiempo para acabarlo todo, por eso el no pensar en coger las advertencias, si bien en todos los equipos uso la 1.0.6 y las mismas librerias instaladas, ya las tengo guardadas. sobre le nombre no es nada que no se pueda explica de forma publica, y que allá por 199x, con los primeros ordenadores en la estacion reemisora de radio donde trabajaba, me lo cargué toqueteando ni me acuerdo el qué, pero habia el DOS y w 3.0x. al dia siguiente lo pusieron en servicio de nuevo y la misma tarde me lo cargué de nuevo. Por la mañana otra vez lo arreglaron y por supuesto, me lo cargué por tercera vez y me dijeron que no sabian porqué tanto miedo por el efecto2000 estando yo en este mundo toqueteando. En aquel entonces mi inglés era algo menos que penoso (aún más penoso que ahora) y no sabia que effect era con dos "f".

saludos

Totalmente entendible lo que planteas.
Yo mismo me quiero matar cuando no hago algo en el sitio y llego a mi taller y resullta ser una tontería de 2 min pero esto tiene que ver con nuestra predisposición en el lugar para hacerlo.
Como dije… los warning son importantes al menos para mi.
Ahora estoy con un código y tengo uno que no puedo resolver… y ya llevo 2 dias investigando y me resulta hasta dificil buscarlo. Asi que imagina a que punto soy cuidadoso.
El equipo irá a un lugar remoto en mi provincia y son muchos kmts y no quiero ir al lugar por eso y luego decir… pq no lo hice bien!!! Si estaba bien, compilaba bien pero luego, BANG!!! se cuelga o hace cosas raras.
Alguien determinó que la ADVERTENCIA tiene sentido. Yo le asigno justamente ese cuidado que el IDE me advierte y le doy el tiempo y de paso mejoro programando.
Mira la tontería, en un tema parecido con SIGNED y UNSIGNED usando millis() justemente comentaba que todo se debe definir como unsigned. Veo hasta librerías donde las variables de comparación son long, porque? Eso da un warning!! en una librería, si en una librería. Claro el programador dirá, si solo comparo algo que ocurre en 1000 mseg no tiene importancia. SI… estoy de acuerdo. No la tiene pero porque dejarlo? Yo no lo hago. No defino nada SIGNED con millis(). El que lo quiera hacer que lo haga.

Bueno. Después de todo el desarrollo del hilo creo que he perdido el hilo (valga la redundancia). ¿La pregunta era si al cargar un sketch se podía alterar el contenido de la EEPROM? Si es así, creo que la respuesta es que sí, aunque se puede corroborar poniendo el IDE en modo verbose durante la subida. Ahí veremos uno o varios comandos avrdude, que es el programa encargado de subir cosas al arduino. Si en alguno de los parámetros se hace referencia, como creo, a un archivo.eep, es que estamos machacando el contenido de la eeprom con ese archivo.eep que probablemente esté vacío. Supongo que esto será evitable, bien modificando alguna opción del ide, bien realizando sólo la compilación y subiendo manualmente sólo el archivo.hex.

Así es noter. Yo trabajo con pantallas FT8xx y si accedes a la EEPROM de la placa Arduino se borra, consiguiendo que la ROM de la pantalla te informe que el sensor táctil no funciona y la tienes que volver a programar. Casí lo mas sensato sería usar una 24Cxxx exterior y creo que sin efecto 2000... :) :) :)

gracias por las respuestas. lo de usar una epp externa queda descartado, ahora funciona y además, lo hace bien. Limpié la epp con el ejemplo del propio ide, puse todo a cero y memoricé los datos de presion másxima y minima y ya debe funcionar unos 9 años, que espero poder jubilarme. A malas y con tiempo, si alguna vez se debe cambiar el mega, supongo que se puede poner en el setup que cargue los datos más recientes de minutos, memorizarlos y después volver a subir el sketch sin estos datos en el setup, o sino, reset total, le meto el virus del efecto2000 y a empezar de cero xD

Sólo por poner la puntilla al tema, un hilo interesante al respecto, por si alguien quiere profundizar un poco más en los misterios de la EEPROM al compilar/subir un programa: https://forum.arduino.cc/index.php?topic=181385.0