Escrito originalmente por Chaly29
Gracias a fenix_jn y MGLSOFT , por lo pronto probare de reemplazar el 16F84A por el 16F628 que es la solución mas rápida
Con respecto a la respuesta de fenix_jn creo que el problema no seria ese ya que el 16F84A de entrada y luego de programarlo anda correctamente si hubiera una falla en la programación el IC-prog me lo diría y si no la hay de principio por que la generaría después, pro lo menos eso es lo que yo creo, pido disculpa si estoy equivocado
Un saludo y suerte a todos
Carlos, te comento que me ha pasado algo similar a lo que mencionas solo que no se me borraba el programa sino la EEPROM.
Como el software leía la eeprom y actuaba en consecuencia, al tomar la eeprom valores inválidos el software hacía cualquier cosa.
De todas formas, en el foro de Microchip siempre hablan de partes que son fallidas. De hecho microchip no aconseja utilizar los F84 para nuevos diseños, en cambio sugiere el F628 que es el que te acaban de sugerir.
Además algunos micros tienen bugs en el hardware, si, aunque suene raro, de vez en cuando se quejan que los 18F452 por ejemplo, tienen un bug en alguno de los modos del SPI.
De todas formas, lo que tu dices es ir en la dirección correcta.
En mi caso, la solución fue que yo me encargaba de hacer el software y otra gente el hardware. En el hardware habia numerosos "bugs" de filtrado. De cosas tan simples como no poner los capacitores de compensacion en un 7805 hasta una fuente de alimentación tan ruidosa que borraba las eeprom con el pico de conexión.
La cuestion se solucionó con una mezcla poco económica de componentes. Inductancia en serie, capacitores de tantalio, una resistencia de bajos ohms en paralelo con el circuito, una buena red de masa que cubra al microcontrolador.
Puede ser que te haya ocurrido esto? que tu software sea eeprom dependiente?
