Electronic – Why does DSPIC33F restarts when timer interrupt flag is addressed

interruptsmicrochipmicrocontrollerpic

I have a peculiar problem with the timer on the DSPIC33F. I need to create a delay function and I have decided to use Timer 2 to count the number of instruction cycles. The function would enable the timer and then wait in the while loop waiting for the interrupt flag to be set. See code below:

T2CONbits.TON = 0;                  // disable Timer 2  
IFS0bits.T2IF = 0;                  // reset Timer 2 interrupt flag
TMR2 = 0;                           // reset timer accumulator
T2CONbits.TON = 1;                  // enable Timer 2

while(!IFS0bits.T2IF);              // Wait until until the timer 2 timeout
IFS0bits.T2IF = 0;                  // reset Timer 2 interrupt flag

T2CONbits.TON = 0;                  // disable Timer 2

The function works perfectly fine if the TMR2 interrupts are disabled. However, if the TMR2 interrupts are enabled, the firmware restarts when the interrupt flag is set. This restart only happens when I run through the code, but not during the step-by-step execution (I am using the ICD3 with MPLab 8.something). I did not setup the ISR for TMR2. All other interrupts are disabled.

Even though I have achieved my goal of creating the delay function, I am still wondering about the possible reasons for the firmware restart. Is that because for some reason I can address the interrupt flag only inside the ISR? Or are there any other reasons?

Best Answer

Page 2 in the PIC33f Interrupts family reference illustrates how interrupt process works for the dsPIC33f:

http://ww1.microchip.com/downloads/en/DeviceDoc/70300C.pdf

When you enable an interrupt (e.g. T2IE) and the interrupt fires it goes to the address location found at the peripheral interrupt vector. if you did not define a legal address for the peripheral the peripheral interrupt vector will have an unknown address (perhaps 0) and when the interrupt will fire it will go to that address and unpredictable things can happen

in your case, assuming the ALTIVT bit (INTCON2<15>) is cleared, when the the TMR2 interrupt fires it will go to the address location found in 0x000022.

when you write:

void __attribute__((__interrupt__, auto_psv)) _T2Interrupt (void)
{

}

you actually telling your compiler that you would like to place the address of the start of this code at address 0x000022 (TMR2 IVT Address)

and when you write:

void __attribute__((__interrupt__, auto_psv)) _AltT2Interrupt (void)
{

}

you are telling your compiler to place the address of the start of this code at address 0x000122 (TMR2 AIVT Address)

Related Solutions

Electronic – Interrupt handling in microcontrollers and FSM example

The first tactic is to architect the overall firmware so that it's OK for interrupts to occur at any time. Having to turn off interrupts so that the foreground code can execute a atomic sequence should be done sparingly. There is often a architectural way around it.

However, the machine is there to serve you, not the other way around. General rules of thumb are only to keep bad programmers from writing really bad code. It is far better to understand exactly how the machine works and then architect a good way to harness those capabilities to perform the desired task.

Keep in mind that unless you really are tight on cycles or memory locations (can certainly happen), that otherwise you want to optimize for clarity and maintainability of the code. For example, if you have a 16 bit machine that updates a 32 bit counter in a clock tick interrupt, you need to make sure that when the foreground code reads the counter that the two halves of it are consistent. One way is to shut off interrupts, read the two words, and then turn interrupts back on. If interrupt latency isn't critical, then that's perfectly acceptable.

In the case where you must have low interrupt latentcy, you can, for example, read the high word, read the low word, read the high word again and repeat if it changed. This slows down the foreground code a little, but adds no interrupt latency at all. There are various little tricks. Another might be to set a flag in the interrupt routine that indicates the counter must be incremented, then do that in the main event loop in the foreground code. That works fine if the counter interrupt rate is slow enough so that the event loop will do the increment before the flag is set again.

Or, instead of a flag use a one-word counter. The foreground code keeps a separate variable that contains the last counter it has updated the system to. It does a unsigned subtract of the live counter minus the saved value to determine how many ticks at a time it has to handle. This allows the foreground code to miss up to 2^N-1 events at a time, where N is the number of bits in a native word the ALU can handle atomically.

Each method has its own set of advantages and disadvantages. There is no single right answer. Again, understand how the machine works, then you won't need rules of thumb.

Electronic – PIC32, XC32, timer interrupt vector not entered

I also had to turn on the global interrupts. Its somewhat of a hidden bit.

It is a bit within the Coprocessor status register, and you can enable it by using:

__asm__("EI");

or disable it by using:

__asm__("DI");

Best Answer

Related Solutions

Electronic – Interrupt handling in microcontrollers and FSM example

Electronic – PIC32, XC32, timer interrupt vector not entered

Related Topic