use of Timer1 and portA interrupts together

[Alexey]

Hi Gentlemen,

I have met an unexpected obstakle today when tried to use TIMER1 interrupt while have PORTA interrupts enabled. Will very apreciate it if someone could look:


@ DEVICE pic16F688, WDT_OFF, INTOSCIO, PWRT_ON, MCLR_ON, BOD_OFF
@ DEVICE CPD_OFF, PROTECT_OFF 'DATA AND CODE MEMORY PROTECTION
define OSC 4
REDLED VAR PORTC.4
GREENLED VAR PORTC.5
clear

CMCON0 = 7 'TURN COMPARATORS OFF
VRCON = 0 'VOLTAGE REFERENCE OFF TO SAVE POWER OPTION_REG.7 = 0
OPTION_REG = 0
ANSEL = %1000 'PORTA4/AN3 IS ANALOG

PORTC=0
TRISC = 0

LINE21: INTCON.3 = 1 'this is the problem!!!
INTCON.4 = 1
LINE23: OCA = %100100 'ENABLES INTERRUPTS ON CHANGE ON PORTA.2 'AND PORTA.5 - ANOTHER part of the PROBLEM
T1CON.0 = 1 'TIMER ON
T1CON.1 = 0 'INT CLOCK Fosc/4
T1CON.4 = 1 'PRESCALER
T1CON.5 = 1 'PRESCALER
T1CON.6 = 0
PIE1.0=1 'TIMER1 OVERFLOW INTERRUPT ENABLE BIT (TMR1IE)
INTCON.6 = 1 'PERIPHERAL INT ENABLE
INTCON.7 = 1 'GLOBAL INT ENABLE
ON INTERRUPT GOTO INT_CHECK
START:
GOTO START 'WAIT HERE TILL INTERRUPTED

DISABLE
INT_CHECK:
IF GREENLED = 0 THEN
GREENLED =1
REDLED=0
ELSE
GREENLED =0
REDLED =1
ENDIF
PIR1.0 = 0
RESUME
ENABLE

When I comment line 21 or line 23 (not necessary both), then my timer interrupt works. If those lines are uncommented, then I have both LEDs ON and nothing work. Interrupt on change (lines marked as line21: and line23: needed for a part of code removed from here to have this text smaller

Please look if I can use Timer1 in this situation at all or have to use Timer0 instead. The MCU is PIC16F688

Thank you very much

Alexey

[Alexey]

I just realized that having both LEDs on means that they trigger too fast. Is it possible that activating Interrupt on Change on PORTA I affect my TIMER1 prescaler somehow?

[Darrel Taylor]

You have enabled Interrupt On Change (INTCON.3), External interrupt (INTCON.4) and Timer1 Ints (PIE1.0).
But the ISR only clears the flag for Timer1. So it will be continuously interrupting when the other interrupts get triggered.

It needs to differentiate between the different interrupts, run separate code depending on which one fired, and clear the appropriate flags before resuming.

Remember that with Int On Change you have to read the port to clear the mismatch condition before you can clear the flag.

[Alexey]

Hello Darrel,

Strange why my interrupts on change affect the timer if I do not press buttons, but yes, clearing those flags makes the timer interrupts work better with regular intervals. Also I added IF PIR!.0 condition in the interrupt handler, but it seems not working well. if interrupt on change flags are not cleared I still have irregular time interwals - probably because of skipping timer handler when other interrupts trigger I do not know what is the reason.

if this something to do with oscillator mode? I use internal osc at 4 MHz, PORTA uses inputs on A.2 and A.5 and A.4 is analog
PORTC is used bor DEBUGIN on C.! and others are outputs

I noticed it works better with HS setting for oscillatio for timer interrupt and Int on change seems need INTOSCIO which mode is correct?

Thanks again,
Alexey

[Darrel Taylor]

Did you add IF tests for all the interrupts you are using? (IOC and INT)
Are you sure you want to use INT? The INT pin is also an IOC pin.

For a 4Mhz crystal, you would use the XT oscillator mode.
The oscillator mode has no effect on IOC interrupts.
And whether it's internal or external, as long as the OSC is 4mhz, it has no effect on the Timer interrupts either.

[Alexey]

Hello Darrel,

Yes, I already learnt that interrupts require a great attention and careful programming Sometimes I could not understand why I am getting different results with (on my opinion) same approach but probably just one little thing outside of my attention makes all difference. I just noticed that simple use of SLEEP in a branch that is not executed when my TIMER1 is used does not allow timer to work :( Simple commenting SLEEP in that branch restores work of the TIMER1. Not sure why. Maybe if I use sleep, PICBASIC reserves the timer1 for it, although I thought it uses TIMER0 (will look how WDT affects this - maybe I had it disabled - will check)
I use interrupt on change on PORTA.5 and RA2/INT on PORTA.2 which helps to filter when A.2 button pressed and when I have signal on A.5 Yes, I do use IFs to handle interrupts

Oh... how many things I need to learn...

Thank you for help!

[Darrel Taylor]

When a PIC goes to sleep, the primary oscillator is shut down.
Since Timer1 gets it's clock from the primaray oscillator, it stops too.

Timer1 can run on an external 32768hz crystal while the PIC is asleep.

[Alexey]

Thanks Darrel,

I am getting crazy with these things... Now I have interrupts from timer working until I call a subroutine. Tried to remove everything from the subroutinemaking it like this:

gosub test

[mister_e]

That snip is not going to help a lot ;) Would be better to post your whole thing.

[Alexey]

Hello Steve,

It looks like the problem was not in the code itself oir not only in code. I do not know for sure where are my mistakes and where are software glitches. Some time ago I contacted Melabs support that my USB programmer programs something wrong and one of the ports I use do not work. (I programmed a batch of chips, soldered and sealed them and they all were bad. Same code programmed by ICD3 was good. I was advised to reset the programmer to factory defaults which I did and it helped. This time I am suffering from unstabile results and really started nervous because I could make a change in a good code, then reverce the change and the code no longer worked. Finally I read my just programmed MCU (programmed using Melabs USB programmer) then read it using Picstart plus and learnt that instead of INTOSCIO it was configured for external clock! (Although it was for sure IUNTOSCIO at the time of programming) Chnging the setting and rerecording the code back into the same MCU (now using Picstart plus) gave a working MCU. Resetting programmer into defaults fixed the problem, but I know for sure that it was in the defaults before. Also I have some screenshots where Melabs programmer says verification ok, then I read the MCU (with same Melabs programmer) and it is empty. Resetting to defaults (which was already reset some time ago change fixed the problem). I have a styrong feeling that I am not going to use that programmer any more as I do not want to reset it every time before programming...

Now I hope that if I change programmer (both hardware and software to Microchip ones) I will have to fight only my mistakes, and all glitches I had were related only to the programmer, not to compiler or assembler...

regards,

Alexey

[mister_e]

I never experimented many weird compiler behaviour since I use PicBasic Pro myself, and I use it since over 10 years. Most of the time I got Error Code #18 to #24... which are located 'round 18 to 24 inches behind the keyboard :D

I can't comment Melabs programmer I don't have it, but I do have PicStart Plus & PicKit 2 (and others). Both gave and still give me good results.. But yeah, I heard a lot of weird programmer behaviour here and there.

[Alexey]

Hi Steve,

I thought I replied yesterday but do not see the post so I repeat (my post about the subroutine above is also only half of the whole text) it looks my computers are having a strike...

Yes, sure most of the time my problems are "Code 18 to 24" :) Fortunately you, Darrel and other people are very helpful here. This time I actually started panic because of unstabile results and I am very glad that it was not my absolute stupidity, it was just some stupidity multiplyed by hardware glitch. At least it is now a bit more relaxing for me to know that my code was not absolutely wrong but just a bit wrong.

Again, thank you for help

Alexey

[Alexey]

Hi Darrel,

Thank you very much for help!

Do I understand correctly that at other than 4 MHz frequency oscillator may affect interrupts? I mean is it affected at 8 MHz or you meant 32 kHz oscillator?

Best regards,


Alexey

[Darrel Taylor]

The OSC frequency doesn't directly affect or interfere with interrupts.

Your original program was set up for 4Mhz, so any change in OSC frequency could affect the way your program handles the interrupts.

The main thing is selecting the correct oscillator mode (XT, HS) for your crystal.