ASM51

Pessoal,


Após resolvido o problema anterior de descobrir o porquê das variáveis não estavarem retendo seus valores, significa que agora tenho outro problema.
Porém, de acordo com a metodologia que estou usando, algumas coisas parecem não estar se 'encaixando'; segue os passos :

Alguem saberia dizer se estou perdendo algum detalhe que não foi verificado ?

1) Logo após o reset, como primeira instrução, inseri a leitura do valor do registrador MCUSR, que sinaliza a fonte do último reset.
Também inseri um break-point na instrução imediatamente após, donde pude ver na janela de watch que o valor no registrador é 0x02:
     

IntReason.png

2) Olhando o datasheet, informa que esse valor é devido ao pino externo nRESET ativado:
     

ResetReason.png

3) Porém, isso fica ocorrendo repetidamente, retornando á todo momento á esse ponto com esse mesmo valor no registrador.
Entretanto, a alimentação está ok:
     

ResetCircuit.png

Muito estranho.

As vezes esqueço de configurar o watch dog no main quando habilito ele no FUSE fazendo o microcontrolador ficar resetando direto.
Isso me deixa de cabelo em pé porque não uso o debug que facilitaria minha vida.

Estranho mesmo ele está informando que é reset externo.

Poisé, e o pior é determinar exatamente o que provocou esse reset.
Não estou conseguindo visualizar nenhum meio de fazer isso.

O que tem na função init?
Você consegue ver ASM gerado(no pic eu consigo)?
Se consegui gerar ASM vai passando linha por linha no debug,e ver na onde que reset aconteça.

Não sei se este microcontrolador tem a opção de configurar o pino do reset como i/o, se tiver da uma verificada nessa configuração.

Acho que já sei como debugar isso, mas não agora que estou sem o laptop.
É o seguinte:

De acordo com a documentação do gcc, se alguma interrupão ( e são muitas no AVR ) estiver 'indevidamente' habilitada, e não houver o vetor implementado no código, ainda que sem nada dentro, no caso de algum evento que a acione, em não existindo o ISR(xxxx) especifico, o programa é direcionado automaticamente para a posição do vetor de reset, o que poderia explicar o fenômento que está acontecendo. Uma das opções para capturar essa ocorrencia, seria criando o manipulador generico abaixo:

cpp code

#include <avr/interrupt.h>
ISR(BADISR_vect)
{
    // user code here
}

Em teoria, e em sendo o caso, apenas inserindo isso aí sem nada dentro, não só confirma a hipotese acima, como também resolve o problema de imediato, podendo deixar pra depois descobrir qual é o bendito flag InterruptEnableXXX que está habilitado. Vou tentar e ver no que dá...

RESOLVIDO!!!!

Funcionou maravilhosamente bem a solucao acima, parou de resetar.
O vetor acima retorna o programa para o ponto anterior á interrupção, o invez de o direcionar ao inicio.

Depois investigo a causa, agora não dá mais tempo, o relogio tá correndo.

Colocar um breakpoint ,e verificar quais interrupções estão habilitadas e com flag da interrupção.