PIC24EP interrupt_active with INTR_CN_PIN not working?

benoitstjean · Posted: Tue Dec 05, 2017 9:46 am

Device: PIC24EP512GP806
Compiler: 5.026

I'm using a bunch of external interrupts -- all the INT_EXT0 to 4 -- and also using three others with INTR_CN_PIN.

After 1 minute of inactivity, the circuit goes to sleep and can only wake-up via external interrupts.

When an interrupt wakes-up the unit, the code calls interrupt_active( _interrupt_ ) for each interrupt like this:

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

Interrupt_active, can only test for the actual interrupt.
The pin number is not an interrupt. It is a mask fed into the interrupt setup to determine which pins can trigger the actual interrupt....

benoitstjean · Posted: Tue Dec 05, 2017 12:49 pm

So I have changed the line to the following:

benoitstjean · Posted: Wed Dec 06, 2017 8:12 am

Anyone?

temtronic · Posted: Wed Dec 06, 2017 8:23 am

OK, I'll take a stab even though I don't use that PIC but heck maybe this will work ??

re:

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

Yours is a very early compiler.

Doing a very basic test:

benoitstjean · Posted: Wed Dec 06, 2017 8:52 am

Hi Jay,

Thanks for the help. I may have found a solution that seems to be working and that's what I'm testing out at the moment.

As TTelmah said, I can't call interrupt_active with the pin mask in the function - I can only pass the interrupt mask - and that makes sense (although it would have been nice from CCS to implement that). Then I tried <interrupt_active( INTR_CN_PIN );> but that still returns '0' and obviously it's not helping.

Again, this scenario is only when the MCU is waking-up from sleep.

So rather than relying on the <interrupt_active()> function to return if a CN interrupt got triggered, given that the MCU can *only* wake-up on an interrupt (all five EXT_INT and two CN_INT), the first thing I do is check all the EXT_INT interrupts with interrupt_active() because these have precedence on the CN interrupts.

If none of the EXT_INT interrupts got triggered, then it means that a CN interrupt got fired in which case I read both inputs using input( pin_name) and check which one changed.

It's working well, thanks for your input though, it's appreciated.

Benoit

jeremiah · Joined: 20 Jul 2010 Posts: 1355

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

Yes.
On some chips they do already give this on recent compiler versions. It depends on the masks that are actually triggered and available.

benoitstjean · Posted: Wed Dec 06, 2017 9:15 am

Hi Ttelmah,

Thanks for digging into this that deep.

I have 5.026, 5.069 and 5.071 but there appears to be a bug or a change introduced somewhere between 5.026 and 5.071 in the area of RAM and ROM space calculations and caused some grief when compiling for the HJ versions. I spent many days with CCS trying to figure-out what was the problem and I don't remember exactly what the outcome was and I'd have re-read all emails exchanged with CCS support.

All in all, along the road, I changed from the PIC24HJ to the PIC24EP but because I still have units with one PIC and other units with the newer PICs, compiling the HJ code in 5.071 was not possible due to the changes introduced with the RAM and ROM calculations (e.g. the code compiled fine with 5.026 but failed with 'out-of-rom' or something on newer versions) so I had to stick with 5.026.

However, the 5.071 IDE contains a feature not available in 5.026 and that's the __BUILDCOUNT__ option. So what CCS got me to do was to use the 5.071 IDE with the 5.026 PCB/PCM/PCH and PCD.

I think that when I compiled the HJ code in 5.026, the RAM was around 88% and ROM around 92% and all worked fine. Then, compiling the exact same code in 5.069 / 5.071 failed with the out-of-rom or something. So although it compiled fine with 5.026, compiling the exact same code for the EP MCU in 5.071 was clearly exceeding the RAM and ROM space of the HJ PICs (e.g. if it was 92% ROM on the HJ, I would have expected it to be around 46% on the EP but it was like 52%). Then compiling the code for the EP version on 5.026 showed a much lower RAM and ROM usage than when it is compiled in 5.071.

All this to say that I am not using the most recent compiler because of the the RAM and ROM calculation issues which are consistent between MCU/compiler versions and I am currently using a butchered compiler.

Benoit

benoitstjean · Posted: Tue Dec 12, 2017 8:16 am

I guess I have another question on the INT_CN interrupt:

When you enable it, you do this:

enable_interrupts( INTR_CN_PIN | PIN_xx );

Since <interrupt_active( int_xx )> function requires only the interrupt mask, when you clear it and disable it, do you need to specify the mask like this:

clear_interrupt( INTR_CN_PIN | PIN_xx );
disable_interrupts( INTR_CN_PIN | PIN_xx );

Or is it like this:

clear_interrupt( INTR_CN_PIN );
disable_interrupts( INTR_CN_PIN );

I can always send an email to CCS also but if the answer is here, then everyone will benefit from it.

Thanks again,

Ben

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

That actually depends on the chip, and the age of the compiler.

On _some_ chips, there is a separate flag set for each pin, though still only one physical interrupt. On these, including the pin number will also clear this flag (on recent compilers).
The interrupt flag itself is always cleared without needing the pin specification.

Though remember that like the old PortB change interrupt the flag will reset immediately unless the pin has been read. It is the act of 'reading' that copies the pin to the latch used for change, so until the pin is read the flag will keep resetting.