ASM51

Caros, estou com um probleminha chato que está me tomando alguns dias...

Estou utilizando o mikroC Pro DsPic para programar o DSPIC30F4013...

O fato é que ao compilar o programa e transferir para o micro (com o PicKit3 original) tudo funciona corretamente: tem um encoder rotativo incremental ligado no pino int0...após "resetar" o micro, a parte da int0 deixa de funcionar! Se envio o hex novamente, funciona! Após desligar e ligar a int não é mais detectada..

Segue trecho de configuração da int0:

Código: Selecionar todos

         // Habilita INT0 Interrupt
      INT0IF_bit = 0 ;                      // Limpa flag da Int Externa0
      INT0EP_bit = 1 ;                      // "0" = Transição de 0 para 1 ativa a INT  // "1" Transição de 1 para 0 ativa a INT ***
      INT0IE_bit = 1 ;                      // Habilita Interrupção por INT0 (Pino 16)
      IPC0bits.INT0IP = 0b110 ;             // Prioridade 6 para INT0

O trecho abaixo é o de atendimento da int0, onde coloquei um pino pra piscar (LED) quando ocorrer a int só pra debug...

Código: Selecionar todos

void Int0Int() iv IVT_ADDR_INT0INTERRUPT {


               INT0IF_bit = 0 ;                        // Limpa flag da Int Externa0
               encoder++ ;
               Delay_us(200);                        // Filtro
               LED = ~LED ;                          // Debug
               escreve=1 ;                          // Debug: Sinaliza ocorrência da Into para escrever no GLCD


}


O programa todo é extenso porém não existem "reconfigurações" da int0...estas são as únicas partes que tratam/configuram a int...

Alguém já passou por isso? Alguma dica?

Para esse tipo de problema, eu coloco uma rotina pela qual posso monitorar os dados relevantes da aplicação pela porta serial e visualizá-los no Teraterm, por exemplo. Quando as coisa vão mal, habilito o #define que cospe os dados que quero para a serial. Nos primórdios eu tive problema justo na serial, aí fazia o dump na eprom, e lia com o gravador. Mas isso foi na idade média do meu aprendizado.

Já me bati no passado porque o compilador não eliminava todos os dados de debug na versão release. Atualizando a ferramenta, o problema resolveu.

Edit: O delay na interrupção pode estar fazendo com que o compilador faça umas tretas para evitar reentrância. pode ser um ponto à investigar.

Removi o delay pra verificar, mas continua com o problema. Também tenho o hábito de deixar um #define para debugar pela serial...inclusive já testei desta forma (debug pela serial) mas não consegui visualizar o não atendimento da int...atualmente estou fazendo o debug por um lcd gráfico com uma rotina extremamente simples.

Bem, agora à tarde descobri uma luz no fim do túnel: a falha é no hardware! Mais precisamente no circuito de reset (pino MCLR) e PLL.

Ou seja, a falha é quando o micro inicia (sequência de power-up)...

Se ponho um "botão" pra resetar manualmente, tudo funciona ok...se reseto pelo PicKit3 ele também funciona (PicKit "baixa" o MCLR).

Lembrando que a microchip recomenda apenas um resistor entre 4,7k e 10k ohms do pino MCLR e o +VCC (pull-up). Nesta configuração de "reset" e com o oscilador interno (FRC) o micro não dá pau...o defeito aparece apenas quando uso o FRC + PLL (7.5Mhz X 16). Ou seja, o "reset" junto com o PLL está dando bronca.

Pesquisando pelo gugui vi alguns relatos parecidos: por exemplo FRC+PLL em 4x e em 16X dá pau, mas não em FRC+PLL 8X...no meu caso dá problemas sempre que ativo o PLL junto com quaisquer frequências.

Testei outros tipos de "reseters": pull up + resistor em série + capacitor cerÂmico 100nf pro gnd...testesi só com dois resistores sem o capacitor...testei com diodo zener + resistor...testei também com o clássico eletrolítico de 10uF pro GND + pull-up de 10komhs...de nenhuma forma o circuito reseta ao startar...

O phoda disso tudo é que também existe a possibilidade de "desativar" o pino MCLR e também "implantar" um POR (power on reset) de 4ms, 16ms ou 64ms escrevendo direto nos registradores: fiz isso também...mas...

Agora entendo porque naquelas placas eletrônicas que eu reparava na empresa em que trabalhava, se fôssem de boa qualidade, sempre existia um chip de reset...

Kraft (ou você também): como utiliza o pino MCLR nos DsPics?

Nunca usei DSPic... Mas já usei o DS1232 e até um mcu (ipo PIC10) externo para fazer um watchdog mais sofisticado. Isso porque o software não era meu e resolver assim era mais viável do que querer consertar um firmware gigantesco.

Se houver um oscilador RC interno, que pudesse ser comutado para o cristal externo e depois PLL, tudo por software, talvez vc tivesse uma alternativa sem mexer no hardware... Mas posso estar viajando...

KrafT escreveu:Se houver um oscilador RC interno, que pudesse ser comutado para o cristal externo e depois PLL, tudo por software, talvez vc tivesse uma alternativa sem mexer no hardware... Mas posso estar viajando...

Kraft...boa dica a sua: meu circuito funciona com o FRC "Fast RC Oscillator" (Oscilador RC interno) + PLL 16X.

Tentei "startar" apenas com o FRC (8 Mhz) e logo depois(por software) tentar ativar o PLL...porém não existe essa possibilidade nesse bendito micro: o PLL só pode ser ativado por "configuração"(quando ocorre a transferência do .hex) e não permite alteração "on the fly"...paciência.

No entanto, após alguns fios de cabelos a menos, consegui resolver da seguinte forma: ativei o Power On Reset do micro ( POR de 64ms), ativei o Brown Out Voltage (Reset abaixo de 4,5V) e ativei o PBOR, conforme print abaixo: Desta forma ficou ok...desliguei e liguei a plaquinha centenas de vezes e não apresentou mais problemas.