mi pic16f876 se traba despues de varios dias trabajando

#1
Hola que tal, he estado trabajando con el pic 16f876 en mplab, el codigo está en ensamblador, es muy grande y es para una empresa privada, asi que no puedo postear el codigo.

En sí, tengo el siguiente problema:
trabaja bien durante una semama ó tres dias ó nueve dias, en un solo dia hace varias veces el mismo trabajo. osea es un ciclo infinito donde siempre debe de hacer lo mismo y lo hace, pero llega a un timepo en que no responde.

Si me pudieran dar ideas de por que se pudiera trabar.

mi pregunta es por que hace lo mismo durante varios dias y despues ya no?, que lo podria obstruir?

saludos y perdon si busco ayuda y no doy herramientas pero si posteo el codigo puedo terminar mal legalmente.
 
Última edición:
#2
Pues mi recomendacion es: Usa el perro guardian, ya se que es latoso pero en ambientes ruidosos es muy comun que pase eso si no se usa esta herramienta que precisamente sirve para encausar bien una posible falla tanto de hardware como de software, ahora bien puedes buscar otro microcontrolador que tenga proteccion contra EMI, si descartas estas posibilidades, es muy pero muy probable que sea tu codigo, en especial las rutinas de retardo, de ahi en fuera no veo porque deba fallas, asi que en conclusion yo pienso que es el ruido electromagnetico o un codigo mal depurado, perdo por no ayudar mas

Cuantanos en que ambiente esta colocado el microcontrolador, porque acuerdate tambien que la temperatura afecta la frecuencia de trabajo, y si en alguna parte de tu programa usas el reloj como algo muy preciso y este se ve afectado por la temperatura pues te puede provocar esa falla, cosa rara pero puede pasar
 
Última edición:
#4
bueno antes que nada gracias por contestar.
ok, el WDT lo tengo deshabilitado, el micro está montado en un pcb dentro de una caja plastica (para proyecto), sobre la temperatura no me preocupa ya que no hay nada cerca que aumente esta variable. sobre esl codigo, lo ha hecho hasta por 2000 ciclos, (este ciclo es que recorra el codigo desde el inicio hasta el final) pero no es un dato constante ya que pueden pasar 100 y se traba.

recibo datos por medio del la uart sin interrupciones, pero antes de salir de esa rutina limpio el bit cren para no almacenar datos en el buffer y asi no obtener un error overrun. de ahi en mas todo lo veo correcto, bueno voy a seguir buscando dentro del codigo aunque ya lo he revisado varias veces.

saludos.

bueno gracias mandrake, creo que "mas ayuda el que no estorba" lo digo por la imagen, me imagino que trabar no es una palabra correcta en tu pais, pero en el mio significa que deja de responder.

saludos
 
Última edición:
#5
Pues mira segun yo y segun lo que me comentas la unica cosa que puede provocar una fallas de ese tipo es decir completamente aleatorios "si es que el software esta bien" es un ruido electromagnetico, podrias checar la parte del oscilador, que hayas usado las tecnicas para minimizar el ruido, no dejar pines flotantes y todo eso, si usas la USART checa que el "imagino" max232 no genere mucho ruido que pueda afectar el funcionamiento del micro, si usas alguna fuente conmutada para alimentarlo tambien checalo porque son muy ruidosas,
 
#6
Ok, muchas gracias, estoy revisando todo sobre los ruidos.


lo malo de este proyecto es que tenemos que esperar hasta una semana para ver si los cambios que hacemos surgen efecto.

Saludos.
 
#7
Hola, te fijaste si tenés interrupciones habilitadas que no usas?
Esto puede llenar el stack o dejar algo en un loop dentro del código interruptivo
 
#8
Ok, tengo solo una interrupcion es la de RB0, cuando esta sucede guardo los registros clave en ram antes de que haga la rutina de interrupcion, posteriormente la hago y al final restaturo los valores guardados en ram a sus registros. los registros que guardo son W, pclath y status.

entonces creo que en las interrupciones tampoco está el problema.

saludos y muchas gracias.
 
#9
El circuito esta en campo o lo tienes en pruebas en laboratorio? lo primero que tienes que hacer es determinar si la causa es de software o de hardware, y para eso necesitas tener 2 circuitos corriendo uno en laboratorio en condiciones controladas y el otro en campo en condiciones reales

Un Bug de software es extremadamente dificil de agarrar, una tecnica que puedes hacer es una rutina que monitoree el estado del microcontrolador y grabe los datos en la memoria EEPROM,, despues al inicio del programa revisas si la bandera de reset del micro se encuentra activada, si es asi entonces procedes a revisar los ultimos datos grabados en la memoria EEPROM y te das una idea de que sucedio

Saludos...
 
#10
muchas gracias a todos.

de hecho tengo varios funcionando, dos en campo y uno en "laboratorio" el que está en el laboratorio lo tengo concectado a la pc y asi lo monitoreo mediante comunicacion serial (rs232), entonces así fué como me di cuenta de que dejaba de responder.

Al principio, cuando vi por primera vez el problema supe en que rutina se encontraba, pero lo raro es que esa rutina la habia hecho ya cientos de veces. Estudié a fondo la rutina y todo estaba bien, revisé los bancos, el paginado, etc.

Posteriormente lo desconecté y lo volví a conectar (reset), despues de dias dejó de funcionar pero en otra rutina que tambien ya habia hecho cinentos si no es que miles de veces.

He revisado fuentes de poder, ruidos ocacionados por motores AC y DC, colocando cerca dispositivos con frecuencias altas, etc y continua perfectamente. Hasta ahoita me ha funcionado durante 14 dias uno de los que tengo en campo, siendo aun asi peores las condiciones de trabajo.

No me lo explico.

saludos y muchas gracias voy a seguir intentando de todo.
 
#11
Pues muy raro, pero sabes que te va dar un monto de risa cuando encuentres la falla y te des cuenta que es una babosada, en fin siento no poder ayudar, solo te recomiendes que cheques lo que tiene que ver con el ADC, y los Timers porque estos generan bastante ruido dentro del micro
 
#12
ok muchas gracias, ahorita ha trabajado bien por casi un mes, pero no dudo que cualquier dia u hora haga lo mismo. Normalmente cuando uno los hace no ve los errores mas simples, es cierto, espero reirme pronto de esa babosada.

He optado por cambiar a C, comenzar y sirve que aprendo mas de ese lenguaje en los micros.

Bueno saludos.
 
#13
pues ami lo que se me ocurre es que revises si en algún punto cuando hace llamados a un retardo, no guardas el valor del registro W para que cuando retorne de él tome el valor del registro guardado.

Saludos
 
Arriba