Interrupt issue

[medelec35]

Hope some one can help.
I have a flowcode routine which is required to loop 30 times. Then enable timer0 and port change interrupt. Frequency of a port is counted. as soon as 1 second has elapsed and frequency is calculated.and interrupt is disabled, then loop stars again.

Problem is after interrupt is disabled, the loop does not restart until 5 minutes later. there is only a 3 second delay added between returning from interrupt an starting loop. on real hard ware this is what's happening. Loop 30 times, interrupt enabled, frequency calculated. interrupt disabled. Halt program for 5 minutes i.e do nothing when program should be running loop.
Start loop.

I am really puzzled why hardware halts for 5 minutes, then continues. Even though there is definitely not any delays in flowcode greater than 3 seconds. Is there's a timer which should have automatically stopped when timer0 is disabled, but its still running until times-out, and sets a flag to continue program?

[medelec35]

I have created two sample programs to demonstrate the interrupt point. One for Flowcode V3 and other for V4

The problem does not occur when interrupt is enabled.
Microcontroller only halts for about 5 Min's when interrupt is disabled.

In the demo, I have created a continuous loop which toggle B7 for 2 seconds. After 11toggles, INT timer0 is enabled. After 1 second
B6 is toggled , interrupt is disabled and at that point the output B7 will stay high for about 5 Min's whilst loop is halted. then loop is restarted after 5 Min's.

EDIT: I have worked out whats going on, but don't know why problem exists.

Not working: any delay (over say a second) in the interrupt macro placed after interrupt disabled icon. This is odd since timer0 should be disabled

works: if no delay or a short delay e.g 10ms. Then loop functions as expected.

[Benj]

Hello Medelec

I tried your V4 copy of the program running on a 16F88 and the device is replicating the problem.

I then reduced the 2 second delays in the main program to 200ms and the program started working correctly.

Hm. (scratches head)

I then attempted to ensure the timer0 was not running by using C code to switch the timer0 source to the external pin. The problem was still present.

I then enabled the boostc software stack by clicking on Chip -> Compiler options and adding this to the end of the Linker Parameters line.

Code: Select all

-swcs 6 2

The problem was still present.

Hm. (scratches head)

I then looked at the code controlling your decision to enable the timer interrupt in your main program.

You had

Code: Select all

count2>10 AND Count = 0

but this should be

Code: Select all

count2>10 && Count = 0

AND is a bitwise logical operation used for masking bits whereas && is if this is true and that is true.

Unfortuantley this did not fix the problem either.

I will have another dig in with this later on.

[Benj]

Hello

Ok I think I have cracked it.

The second delay code is a function located inside the microcontrollers memory.

The main program calls the delay function and while inside the delay function the interrupt kicks in.

This calls another delay function which reinitialises variables and memory locations used by the delay routine.

When these delays have finished the interrupt routine drops the program back into the main programs delay routine. As the variables used by the delay have been corrupted the delay takes much longer then expected to complete.

A way around this is to,

A) use a loop of 40 counts with a delay of 100ms inside your interrupt routine. Note: if you have ms delays in your main program then this is again a bad idea.
B) Find a way not to use delays inside your interrupt service routine.

[medelec35]

The main program calls the delay function and while inside the delay function the interrupt kicks in.

This calls another delay function which reinitialises variables and memory locations used by the delay routine.

The interrupt timer is disabled before the time delay.

[Benj]

Hello

Yes the timer is disabled but the timer is not the issue. The issue is the delay function which is already running in the main before the interrupt occurs. Then the delay inside the interrupt routine is processed and when you return to the delay in your main the variables have been corrupted.

One way to get around this would be to set a flag in your interrupt and then process the flag in your main. This way you would never be interrupting a delay with another delay.

[medelec35]

O ic < (pun alert!. ) Thanks. It does make sense what you are saying.