Timer4 interrupt makes the 18F6621 reset

[Schmobol]

I want to use the timer4 for the first time on a 18F6621 and surprisingly, the µc resets when I enable it ! Here is the interrupt routine :

#int_TIMER4
void Timer4_interrupt_processing()
{

if (temps_inter_salve==0)
{
if (premiere_interruption)
{
disable_interrupts(INT_TIMER0); /* on desactive timer0 pour ne pas perturber la vitesse de la LF */
if (configuration.mode_f!=lf) disable_interrupts(INT_EXT1); /* debut emission lf on desactive l'interupt ext */
if (bit_test (trame_lf[indice_tableau],(15-indice_bit))) commande_lf=0;
else commande_lf=1;

cpt_salve_lf++;

if (cpt_salve_lf<50)
{
indice_tableau=(int)(cpt_salve_lf/16);
indice_bit=cpt_salve_lf%16;
}
else
{
indice_tableau=(int)((cpt_salve_lf+14)/16);
indice_bit=(cpt_salve_lf+14)%16;
}
premiere_interruption=FALSE;
}
else
{
FLF=commande_lf;
if (bit_test (trame_lf[indice_tableau],(15-indice_bit))) commande_lf=0;
else commande_lf=1;

cpt_salve_lf++;

if (cpt_salve_lf<50)
{
indice_tableau=(int)(cpt_salve_lf/16);
indice_bit=cpt_salve_lf%16;
}
else
{
indice_tableau=(int)((cpt_salve_lf+14)/16);
indice_bit=(cpt_salve_lf+14)%16;
}



if (cpt_salve_lf>=148)
{
FLF=0; /* fin trame */
if (configuration.mode_f!=lf) enable_interrupts(INT_EXT1); /* fin de trame lf on reactive l'interrupt externe */
numero_salve_lf++;
if (numero_salve_lf>=NOMBRE_SALVES_LF)
{
disable_interrupts(INT_TIMER4);
clear_interrupt(INT_TIMER0);
enable_interrupts(INT_TIMER0);
}
temps_inter_salve=DUREE_INTER_SALVE; /* (16*2)+(18)+(8*2*4)= 114 */
premiere_interruption=TRUE;
}
}
}
else
{
temps_inter_salve--; /* periode intersalve */
cpt_salve_lf=0;
indice_bit=0;
}
}


Any idea ?

CCS 3.189

[Neutone]

When posting code use the code format button. Other wise the leading spaces are removed. This makes it more dificult to read.
Code display: [ code]code[/code ] (alt+c)

[Schmobol]

You're right, sorry !

[Schmobol]

After a couple of tests the problem isn't linked with the interrupt routine. The reset occurs whenever I activate the timer4 interruption even if there's no code in the inerrupt routine. Weird ? It might not be related to the compiler !

Any idea are welcomed !

PIC18F6621

CCS 3.189

[Haplo]

Since the problem is not the ISR, post the rest of your code.

[prwatCCS]

I would check the .lst file to be sure that the isr is correctly resetting the irq flag. Otherwise you may be continually stuck in an isr and be suffering from a watchdog timeout.

Dont forget it always helps to post your setup code and config data. You may need to comment out the line #nolist in the file 18F6621.h to see the irq code generated by the compiler.

regards
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK

[Schmobol]

It does clear the timer4 interrupt flag before exiting interrupt routine. It does a (MOVLB 0, how could it hurt ?) and returns to the dispatcher for restoring the context.

BCF PIR3.3
MOVLB 0
GOTO 007C

Otherwise, Haplo, regarding the rest of the code, I have more than 4500 lines in this program. What should I post ?

[Haplo]

Well this is a difficult one. It can be a timing issue. How often does your Timer4 interrupt?

As you might know interrupts have a very high latency in PIC18s (both the PIC and the CCS code). If the Timer4 interrupt is happening too often it might be corrupting some data somewhere else, especially if you have any software UART/I2C/....(for example if your timer interrupts every 100us, all the software UART data with baud rates faster than 4800bps would get corrupted). It might cause a corrupt byte to be sent/received, and put your code in a state that you never expected it to enter in normal situations, resulting in a watchdog reset.

[prwatCCS]

A few questions :

What happens if you disable the WDT ?

What happens if you service the WDT from within your dummy tmr4 iq handler ?

What happens in the tmr0 irq handler - are you simply spending too much time in the two irq handlers ?

What priority have you given to the irqs ?

A line like
#priority timer2,rda2,timer1,timer0,tbe

sets the order in which they get despatched ...

regards
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK

[Schmobol]

YEs I'm aware of the huge latency when FAST interrupt isn't used. In this very same program I use fast interrupt on INT_EXT1 to decode a bunch of different telegrams carried by RF 433 MHz with a automatic recognition of 7 different possible emission source. Some of these telegrams are coded in manchester 9600 baud witch means that I have to catch (with lower tolerance) times no greater than 36 µs while doing a lot of things in the background. In other words I 'm very tight with the throughput.

But the thing is that this interrupt isn't even activated when I need the timer4 interrupt. At this point of time, only TIMER 0 is activated !

Moreover, I haven't found anything in the 18F6621 errata sheet.

I managed to tweak my program to spare a timer and avoid using timer 4, but still, this remains a mystery...

Any other idea are welcomed