Odd Interrupt Behaviour - One Int calls two ISRs

[jay_dee]

I would appriecate some input on the attached FC.
I have created two Custom Interrupts that use ECCP1 of a PIC 18F4680. One is used to measure an RPM pulse, the Other measures a SPEED Pulse.
Importantly, they will only get enabled individually.

(long story short, I cant use CCP1 and ECCP1 for individual signals as there is a conflict with ECAN and CCP that I can resolve yet.)
I'm not concearned about switching bweteen two pulse streams into a single ECCP1, hardware is handling that.
In software I will enable one Interupt, once is has sampled its signal, it will be stopped and then I'll change to the second and sample that.

But
Odd Behaviour, I have two interrupts setup and the associated ISR (Interrupt service Rountines).
However when testing with just a single Interupt, and the other explicitly Disabled, both ISR's seem to be getting run?

I see 'COUNT' values unique to each ISR getting updated.
How can this be happening, nothing should be calling the second ISR?

INT_TEST_v1.fcfx

(65.34 KiB) Downloaded 7 times

This one has me confused!

[jay_dee]

So I think its something in the handler code,

Code: Select all

if (PIR2bits.ECCP1IF)
{
FCM_%n(); // call selected macro
}

Maybe I need to explicity select the ISR I wish to target, setting a different one for each version of the Interrupt.
So how do I specify the ISR Macro in the handler C?
I tried changing the line starting FCM_ to this but did not work.
FCM_PULSESPD_ISR();

[mnfisher]

It looks like a bug: The code for the interrupt is generated even if the interrupt enable macro is disabled - so in your code:

Code: Select all

void MX_INTERRUPT_MACRO(void)
{

  //Handler code for [ECCP1 Interrupt]
  if (PIR2bits.ECCP1IF)
  {
  FCM_PulseRPM_ISR(); // call selected macro
  }

  //Handler code for [ECCP1 SPEED]
  if (PIR2bits.ECCP1IF)
  {
  FCM_PulseSPD_ISR(); // call selected macro
  }

}

Although the interrupt enable for PulseRPM_ISR is disabled - as this occurs first in the code - it will always be called on an interrupt (and since it clears ECCP1IF - PulseSPD_ISR will never get called)

The FCM_%n() - allows the selection of the macro from the dropdown - you could use the macro name - note that they are not capitalised (unlike variable names) - so you would use FCM_PulseSPD_ISR.

Personally - I think the easiest way to handle this is to have a 'flag' variable and use this to 'choose' the interrupt handler used - either in the macro itself (and then can be done in Flowcode) - or in the interrupt enable code (done in C) - either was is similar (if(flag) do_onething; else do_theother;

Martin

[mnfisher]

It looks like a bug: The code for the interrupt is generated even if the interrupt enable macro is disabled - so in your code:

Code: Select all

void MX_INTERRUPT_MACRO(void)
{

  //Handler code for [ECCP1 Interrupt]
  if (PIR2bits.ECCP1IF)
  {
  FCM_PulseRPM_ISR(); // call selected macro
  }

  //Handler code for [ECCP1 SPEED]
  if (PIR2bits.ECCP1IF)
  {
  FCM_PulseSPD_ISR(); // call selected macro
  }

}

Although the interrupt enable for PulseRPM_ISR is disabled - as this occurs first in the code - it will always be called on an interrupt (and since it clears ECCP1IF - PulseSPD_ISR will never get called)

The FCM_%n() - allows the selection of the macro from the dropdown - you could use the macro name - note that they are not capitalised (unlike variable names) - so you would use FCM_PulseSPD_ISR.

One way to handle this is to have a 'flag' variable and use this to 'choose' the interrupt handler used - either in the macro itself (and then can be done in Flowcode) - or in the interrupt enable code (done in C) - either way is similar (if(flag) do_onething; else do_theother;
Or - the interrupt handler 'checks' a flag 'enabled' - and runs if appropriate:
if(SPD_ISR_ENABLED) { do_speed }
Again this can be done in FC - or in C as required


Martin

[jay_dee]

Thanks Martin,
Great insight, I will have a look as you suggest.

Ahh.... this is great to know. C Code Macro references -- "note that they are not capitalised (unlike variable names) - so you would use FCM_PulseSPD_ISR."
J.

[Steve-Matrix]

Thanks, both. I have fixed this for the latest Flowcode codebase, so it should not be a problem in future Flowcode releases.