Interrupciones que dejan de funcionar (MPLAB X + Assembler)

#1
Saludos.

Pues como dice el titulo, y no me ha pasado solo una vez sino varias y en diferentes programas con el PIC16F877A.

La historia es que escribo un programa en assembler y MPLAB X (Ver 3.61) utilizando alguna interrupcion, Timer1 o bien interrupcion externa por RB0 que son las que mas uso.
El caso es que el programa compila sin errores y funciona perfectamente. Pasa un tiempo determinado y, al compilarlo de nuevo sin errores de ningun tipo, ya no salta la interrupcion (el resto del programa, sin problema aparente)
.

Es el mismo programa, no ha cambiado nada, solo el dia de compilado


Comprobando con el simulador del MPLAB X, en el registro INTCON, el flag correspondiente (INTF) salta, pero el programa sigue su curso sin hacer caso del flag ni de nada.

Quemando el PIC y probando en protoboard lo mismo, la interrupcion no salta...


Alguien tiene alguna idea de que porque puede pasar esto? Misma experiencia? Agradecere cualquier ayuda

No quiero parecer desesperado pero llevo varios dias con esto y me esta empezando a echar humo la cabeza
 
#2
Sin código, sería adivinar. Es cosa de ver configuración de registros.
Si usas librerías, verifica que no estén deshabilitando las interrupciones.
Programar con DEBUG activo hace que el microcontrolador solo funcione en modo de depuración.
Y hablando es este último, depurar con ICD puede servir bastante para encontrar el problema.
 
#3
Gracias por la rapida respuesta

Sin código, sería adivinar.
El codigo no ha cambiado y tampoco es tan complicado, sinceramente no creo que el problema sea ese....

Programar con DEBUG activo hace que el microcontrolador solo funcione en modo de depuración.
Hummmm, interesante, no lo sabia...
Lo siguiente seria saber como se desactiva... voy a investigar un poco

Pues parece que se ha solucionado

En el MPLAB he configurado el menu FILE → PROJECT PROPERTIES → HARDWARE TOOLS y he cambiado "Simulator" por "PIC KIT 3".

Al hacer BUILD PROJECT he probado el archivo HEX resultante en el Proteus (ahora no dispongo de ninguna placa) y parece que la interrupcion ha vuelto a funcionar.

Gracias por la ayuda.
 
#4
---Actualizacion 2019/4/13---

Casi un ano ha pasado desde que escribi este post pero no quiero empezar uno nuevo.

El caso es que me sigue pasando el mismo problema explicado arriba.

Un programa que compila sin problemas en el MPLAB 7.53 y funciona bien en el circuito real, al pasarlo al MPLAB X 4.15 compila sin problemas pero, al pasarlo al circuito real, deja de funcionar correctamente alguna interrupcion, en este caso, la externa por puerto RB0.

Si usas librerías, verifica que no estén deshabilitando las interrupciones.
No uso librerias, solo un archivo .asm escrito en assembler.

En el MPLAB he configurado el menu FILE → PROJECT PROPERTIES → HARDWARE TOOLS y he cambiado "Simulator" por "PIC KIT 3".
La vez anterior esta parecia ser la respuesta pero ahora tampoco funciona.

Problema del codigo? si no ha cambiado nada como puede ser problema del codigo?
Configuracion del MPLAB X? he cambiado aqui y alla pero parece no cambiar nada.....

No ha tenido nadie un problema similar?
Alguna idea o consejo?

Gracias por adelantado

POSDATA: lo siento por los acentos pero este ordenador no tiene teclado en castellano (este es otro tema a tratar...)
 
#5
hola, disculpa que me meta, yo cuando tengo un problema asi lo que hago es hacer una rutina que solo haga trabajar a la interrupcion.

COPIO el programa hecho , el que da problemas ( asi no modifico nada ) y borro casi todo ( lo innecesario) y me queda ademas de lo inicial ( configuraciones) solo una rutina minima que usa la interrupcion.
ponele prender y apagar un led o algo asi.
y lo dejo andando .

asi pruebo SOLO lo que SUPONGO esta fallando .
 
#6
Yo cuando tengo un problema así, lo que hago es hacer una rutina que solo haga trabajar a la interrupción.

COPIO el programa hecho, el que da problemas (así no modifico nada) y borro casi todo (lo innecesario) y me queda además de lo inicial (configuraciones) solo una rutina mínima que usa la interrupción.
Yo hago algo similar, pero por pasos.
Voy eliminando rutinas e incluso configuraciones hasta encontrar cuál es la que causa el problema.
 
#7
Gracias por sus respuestas.

hola, disculpa que me meta
No hace falta disculpa, cualquier ayuda es bienvenida(y)

yo cuando tengo un problema asi lo que hago es hacer una rutina que solo haga trabajar a la interrupcion.
Es decir que estamos suponiendo que el problema esta en el programa...
Pero el programa no ha cambiado ni una sola linea, lo que ha cambiado es la version del Mplab.
No soy programador profesional y hago esto como hobby asi que os pregunto a los que sabeis si esto es posible.
 

Dr. Zoidberg

Well-known-Papá Pitufo
#8
No soy programador profesional y hago esto como hobby asi que os pregunto a los que sabeis si esto es posible.
Claro que puede suceder por cambiar la version de MPLAB, pero a menos que ese problema esté reportado, para lo cual hay que leer el por qué de los cambios de version (cosa que seguramente no has hecho) es altamente improbable que suceda.
Dicho esto, y dado que pareces tener poca experiencia, te recomiendo lo siguiente:
1- Dejar de discutir con los que saben y seguir sus indicaciones.
2- Publicar el fuc** codigo para que puedan analizarlo y probarlo Si el codigo es secreto, no deberias preguntar acá.
3- Cualquier duda, goto 1
 
#9
Es decir que, ¿estamos suponiendo que el problema esta en el programa?
Si el problema es que una interrupción externa no funciona, descartando el hardware, eso es lo más lógico.
De igual forma y más lógico también sucedería con una interrupción interna.

¿Qué se hace ante este tipo de situaciones?
Bueno, la más elemental ya se te ha dicho, ir eliminando rutinas y configuraciones para determinar la causa.
Sucede que algunas veces no nos damos cuenta que algunas rutinas pueden afectar a otras.
¿Por qué? Porque muchas veces nos olvidamos de las dependencias de otras rutinas y sin más colocamos código que las afecta.

El uso del ICD (In Circuit Debugger) es algo que muchos programadores no hacen uso y ahí está disponible en varias familias de PIC
No lo usan porque se les hace complicado o porque jamás habían oído o leído sobre eso.
Esta importante característica nos facilita la tarea de depurar un programa por medio de interrupciones colocadas estratégicamente en el programa para ir viendo como va generándose un proceso.
El ICD es en tiempo real y varios entornos posibilitan su uso, pero se requiere de un programador que lo soporte. Por ejemplo: PICkit 3
Cabe aclarar que debe activarse y que únicamente el PIC funcionará para ello cuando se activa, como lo mencioné anteriormente.

El mismo Proteus también funciona como depurador cargando el archivo *.COF y entrando al modo de depuración con el botón "Pause"
En ese momento se colocan los puntos de ruptura dentro del código en las partes en las que se piensa está el conflicto.
Lo que sigue tan solo es dar avance por pasos e ir viendo lo que sucede.
Para eso también se deben mirar los registros, valores de variables y cualquier otra cosa que nos indique posibles problemas.

Ahora que si esto del ICD les resulta complicado, también se puede depurar por USART.
Solo que esto ya es ingresando código estratégico en el programa.

No se necesita ser un experto para encarar problemas de este tipo, lo que hace falta es un poco de lógica y noción.
 
#10
Gracias D@rkbytes por la amplia respuesta

El uso del ICD (In Circuit Debugger) es algo que muchos programadores no hacen uso y ahí está disponible en varias familias de PIC
No lo usan porque se les hace complicado o porque jamás habían oído o leído sobre eso.
Hasta ahora solo utilizaba el simulator del Mplab, el icd no me he metido nunca con el, lo admito.

No se necesita ser un experto para encarar problemas de este tipo, lo que hace falta es un poco de lógica y noción.
Y tiempo jejeje.
OK intentare probar el programa por partes, poco a poco para buscar donde esta el problema.
Si descubro algo os lo contare.

Gracias por la ayuda
 

Temas similares


Arriba