Problemas de reinicio del 16F84

[guancho2002]

Buenas, como viene siendo habitual vuelvo a la carga con otra pregunta... tengan paciencia conmigo   
Resulta que llevo desarrollando un proyecto con un 16F84 al cual tras haber programado bastantes líneas de código, este llega un momento en el que se reinicia solo. Lo he estado comprobando y es muy curioso porque en el inicio del programa no le permito que continue hasta que no pulse un boton. El watchdog lo tengo desconectado y el pin de reset a 5V.
Lo curioso es que cuando anulo uno de los CALL que hay casi terminando el programa, el problema desaparece. No se si recuerdo mal pero creo que leí en uno de los hilos del foro que cuando hay un RETURN sin haber tenido una llamada mediante un CALL, este se resetea. Lo he comprobado y está correcto.
Me surge una duda, Cuando hago llamadas mediante CALL estas se almacenan en la pila y no desaparece hasta el RETURN, pero, con GOTO ¿ocurre lo mismo? creo recordar que no, ¿verdad? Os comento esto porque he llegado a pensar que pueda haber un volcado de pila pero mirando el programa no llegan a anidar mas de 3 o 4 call.
¿Que se os ocurre?
Gracias.

[vszener]

Si haces un goto dentro de una subrutina para pasar a otra subrutina se te reseteará.


Suerte!!!

[maunix]

Si haces un goto dentro de una subrutina para pasar a otra subrutina se te reseteará.

vszener, tal vez no te he entendido lo que has querido decir, pero no coincido contigo en que usar un goto para pasar de una subrutina a otra hará resetear el PIC. 

Si el goto está bien hecho, no veo razón por la cual deba ocurrir esto.  De hecho el goto es la forma de no necesitar la pila para hacer 'saltos' de programa. 


guanacho2002, creo que tienes un problema en tu código.  El código te está saltando a un lugar que no esperas que te salte y ahí 'algo' haces.

Está bien lo que dices que un return si no hay un dato en la pila, hará "como si fuera un reset" en el pic.  Yo mismo he dicho eso hace un par de posts (aunque tal vez lo leíste del post de otro usuario) y la razón es que al no tener datos en el stack de 'calls' el pic hace un rellenado del program counter con ceros 0x0000. 

Si el problema se soluciona modificando tu código, entonces el problema es casi con seguridad de firmware (aclaro esto porque a veces el hardware puede hacer resetear a tu pic.  Ej poner tensiones negativas en un pin A/D).

Si quieres podemos 'echarle' una mirada a tu código.  Otra cosa que puedes hacer es correr tu firmware con el 'trace' habilitado en el simulador MPSIM que viene con el MPLAB IDE.

Pones que haga un 'breakpoint' cuando hace un reset, eso lo defines en el apartado Settings del Menú Debugger.  El trace lo que hace es guardarte las últimas 8000 (si mal no recuerdo) líneas de código y de esa forma puedes ver en las líneas próximas anteriores al reset qué ha ocurrido.

Tal vez no estes haciendo un reset sino que tu pic esté yendo a una dirección que esté mal configurada o cerca del final del programa y que siga ejecutando instrucciones hasta que el Program Counter rebase y se haga 0x0000.

Saludos

[Deimos]

Lo que dice maunix me parece mas acertado que lo que dice vszener. En el momento que el contador de programa está a cero, reseteará la maquina. No veo coherente que la máquina se resetee por los gotos, a no ser, como ya se ha dicho, que se mande al puntero a un lugar del programa donde no hay nada, y acaba cargando 0x0000 en el PC. Si el watch-dog está deshabilitado, y sabes que no tienes problemas de tensiones en las entradas, casi se podria asegurar que el fallo es de programa.

Cuelga el fuente que le echaremos un vistazo entre todos.

Atentamente

Deimos

http://astroelectronica.iespana.es/

[vszener]

Creo haber leído que estamos hablando de subrutinas, ¿dónde se almacena PC al llamarse a la subrutina? en la pila, por lo tanto si estamos dentro de una subrutina y hacemos un goto a un trozo de codigo de otra subrutina distinta, no estamos anidando subrutinas, no!!!, simplemente estamos volviendo loco al PC, a no ser, como ha indicado maunix que el goto se haga correctamente y hacerlo correctamente significa el recuperar después los datos almacenados en la pila (¿es un método bueno de programación? ), sino el pic se 'reseteara' (o se quedara colgado), pero ¿para hacer subrutinas anidadas hace falta el goto? pues no, porque no es correcto, para eso esta la instrucción call que guarda correctamente los parametros en la pila para su correcta utilización, y por supuesto los correspondientes return.

En resumen, cada vez que hablemos de subrutinas tenemos tener claro que los datos de almacenan en la pila, por lo tanto para volver al programa principal sin problemas tendremos que utilizar el correspondiente return para salvar dichos datos de la pila, sino, pues bloqueo o reset del pic...


Suerte!!!

[maunix]

Creo haber leído que estamos hablando de subrutinas, ¿dónde se almacena PC al llamarse a la subrutina? en la pila, por lo tanto si estamos dentro de una subrutina y hacemos un goto a un trozo de codigo de otra subrutina distinta, no estamos anidando subrutinas, no!!!, simplemente estamos volviendo loco al PC, a no ser, como ha indicado maunix que el goto se haga correctamente y hacerlo correctamente significa el recuperar después los datos almacenados en la pila (¿es un método bueno de programación? ), sino el pic se 'reseteara' (o se quedara colgado), pero ¿para hacer subrutinas anidadas hace falta el goto? pues no, porque no es correcto, para eso esta la instrucción call que guarda correctamente los parametros en la pila para su correcta utilización, y por supuesto los correspondientes return.

vszener creo que estas mezclando las cosas o realmente no entiendo tu punto.

Yo podría hacer un call a una sección de programa, y luego en esa sección hacer 24000 gotos y el Program Counter no se volvería loco para nada, ni la pila se modificaría.

El Program Counter cambia todo el tiempo! sino no podrías ejecutar una instrucción y luego la siguiente.

Ejemplo

Código: ASM

1. call _SUBRUTINA
2.         nop                   ; <--- aqui volverá luego del return en _SUBRUTINAcuatro
3.  
4. _SUBRUTINA
5.         movlw   0x04
6.         goto    _SUBRUTINAuno
7.  
8. _SUBRUTINAuno:
9.         goto    _SUBRUTINAdos
10.  
11. _SUBRUTINAdos:
12.         goto    _SUBRUTINAtres
13. _SUBRUTINAtres:
14.         goto    _SUBRUTINAcuatro
15.  
16. _SUBRUTINAcuatro:
17.         return

El ejemplo es muy sonzo e inútil pero no por eso está mal, ni vuelve loco al program counter ni nada por el estilo.

Espero nos hayamos entendido ahora.

Saludos

[guancho2002]

Gracias por vuestras aclaraciones pero veo un problema... me comentáis que es cuando llega a un GOTO no correcto o cuando no se hace un buen anidamiento de los CALL, pero si al principio del programa lo fuerzo a que si no pulsa un botón el programa no continuará y este sigue haciendo el reset, ¿a que es debido ya que ni si quiera llega al primer CALL o GOTO?
Voy a seguir echandole un vistazo y si no encuentro nada lo cuelgo para que lo comentemos.
 

[maunix]

Gracias por vuestras aclaraciones pero veo un problema... me comentáis que es cuando llega a un GOTO no correcto o cuando no se hace un buen anidamiento de los CALL, pero si al principio del programa lo fuerzo a que si no pulsa un botón el programa no continuará y este sigue haciendo el reset, ¿a que es debido ya que ni si quiera llega al primer CALL o GOTO?
Voy a seguir echandole un vistazo y si no encuentro nada lo cuelgo para que lo comentemos.
 

1) Mmm, ¿Estás seguro que tienes el watchdog deshabilitado? Si bien desde tu código puedes 'configurar' los fuses para que sean guardados en el archivo .HEX, también es cierto que al momento de programar tu PIC tal vez lo habilites sin querer.

2) También puede ser que tengas una interrupción habilitada, al ocurrir la misma irá a 0x0004.  Si no tienes nada en esa parte del programa, pues bien... sería "casi como si fuera un reset" ya que estarias reiniciando de nuevo tu soft.


Cuando tengo problemas, trato de 'aislarlo'.  En tu caso, sería que solo compiles el código que usarás para hacer la prueba del botón y ahí ver si se resetea. 

¿Porqué no subes tu código o al menos un pequeño fragmento que es donde tienes problemas?

[vszener]

Haber si nos entendemos...jeje

Código: ASM

1. call _SUBRUTINA
2.               nop                   ; <--- aqui volverá luego del return en _SUBRUTINAcuatro
3. _SUBRUTINA     
4.                 movlw   0x04   
5.                 goto    _SUBRUTINAuno
6. _SUBRUTINAuno: 
7.                 goto    _SUBRUTINAdos
8. _SUBRUTINAdos: 
9.                 goto    _SUBRUTINAtres
10. _SUBRUTINAtres:
11.                goto     _SUBRUTINAcuatro
12. _SUBRUTINAcuatro:      
13.                return

El programa que has puesto simplemente llama a una subrutina, las demas llamadas_SUBRUTINAx donde x es una, dos, tres o cuatro, no son subrutinas en sí, sino saltos de codigo dentro de la única subrutina que has puesto, la llamada _SUBRUTINA, así como lo has escrito está claro que no hay problema, porque el PC ha sido previamente apilado y se desapila correctamente con su respectivo return final, pero eso no e slo que yo indicaba o queria decir, yo me refiero a que si tú llamas a una subrutina y dentro de la misma mediante un goto vas a una porción de programa de otra subrutina distinta (que no esté dentro de la misma subrutina) el pic se te quedará colgado o se 'reseteará' a no ser que desapiles bien los datos.

Ejemplo:

Código: ASM

1. call  _SUBRUTINA
2.         nop
3.  
4. _SUBRUTINA
5.        nop
6.        nop
7.        goto    dir1
8.        nop
9.        return
10.  
11. _SUBRUTINA2
12.      nop
13.      nop
14. dir1:
15.     nop  
16.     return          ; pic se quedará colgado o se 'reseteará'

Aquí si realmente hay dos subrutinas, en el ejemplo que has puesto solamente hay una con muchos saltos de programa.


Suerte!!!

[Modulay]

vszener en la primera llamada a _SUBRUTINA el pic creo que no se "resetea".
Lo que ocurre tras la ejecución del goto es que se encuentra un return y lo que hace es coger de la pila la dirección correspondiente al lugar desde donde se llamó a _SUBRUTINA,que es la dirección que se apiló cuando se produjo la llamada a la misma,por lo que volvería a dicho punto.
Una vez ocurrido esto _SUBRUTINA se volvería a ejecutar,pero ya simplemente por el lugar en el que está ubicada...volvería a ejecutarse el goto y entonces si nos encontraríamos un return con la pila supuestamente vacía,por lo que si se volcaría sobre el PC la dirección de inicio.
El pic no sabe de subrutinas ni de salidas de contexto.El unicamente sabe que si se encuentra un goto,vuelca un valor sobre el PC...si se encuentra un call,apila la dirección actual y vuelca sobre el PC la dirección que acompaña al call...si se encuentra un return,desapila y vuelca ese valor desapilado sobre el PC

[BrunoF]

Hola.
vszener: La instruccion GOTO no se almacena ni guarda en el STACK(PILA) del PIC. El PIC solo obedece y salta, fijate sino, que el pic no diferencia ni sabe donde comienza o termina una subrutina. Solo sabe que debe cargar o descargar el STACK cuando se lo indicas, y eso es lo unico que necesita.
Por lo tanto, ambos ejemplos que pusiste son identicos para el PIC.
Si entro a una subrutina, puedo saltar a donde quiera. Lo unico que debo respetar luego, es que en algun momento, descargue el STACK, ya sea con un RETURN, RETLW o un RETFIE.
Deberias simularlo para aclarar las dudas.
Volviendo al hilo principal, por ahi, el problema de reseteo es un underflow del STACK.
Saludos.

[maunix]

vszener no creo haga falta agregar más a lo que ha dicho Modulay respecto al PC , goto y calls.

Si te fijas en mi ejemplo, lo que puse no son 'subrutinas' dentro de una subrutina sino , partes de la misma subrutina.

Como bien dijo Modulay el pic no sabe de 'subrutinas', esos 'labels' son simplemente para facilitarnos la codificación a los mortales pero no para otra cosa.

Es lo mismo que tu has hecho.  No importa si lo llamas con CALL o GOTO.  Para el caso es lo mismo.  El CALL te da la ventaja de que al hacer un 'return' vuelves a donde lo habían llamado.  Esto permite que el mismo código sea llamado una y otra vez de una forma muy simple. 

El goto no permite esa potencia, al menos no así por defecto (aunque se pueden hacer rutinas con goto's configurables que retornen a quien las llamo).

Saludos

[jfh900]

Llegado a este punto es mejor dejar de elocubrar y pedir a guancho2002 que postee el código y ver que puede pasar.

Un saludo

[maunix]

Llegado a este punto es mejor dejar de elocubrar y pedir a guancho2002 que postee el código y ver que puede pasar.

Un saludo

Jesús, el tema siguió por una veta diferente esperando a que guanacho2002 suba su código.

Este pedido se lo hice hace varios posts arriba --> Pedido de Código

Saludos

[guancho2002]

Perdonadme todos por la tardanza pero es que he tenido un día...
Ya solucioné el problema que como bien dice BrunoF, era un volcado de pila. El problema es que como utilizo macros de un libro que compré y no me he parado a mirarlas pues me voy confirando en los saltos que yo programo y no me daba cuenta que al hacer una llamada a una macro esta internamente tenía saltos a otra, con lo cual todo era ir sumando... 
De todos modos incluso así aprendo cosas que no tenía claras como es el tema del GOTO que tanto habéis hablado en estas respuestas. Todos los días se aprende algo.
En cuanto a lo de subir el programa no lo he hecho porque era bastante extenso pero si alguien está interesado que lo diga y lo subo. No es mas que un simple contador programable.
Gracias a todos.