PIC16F18326 Interrupt error

[DirkB]

Hello,

I've noticed that on the PIC 16F18326, interrupts always trigger on both edges when a falling edge is set. This applies to the IOC and INT pins.

Regards

[mnfisher]

Can you post a simple demo showing this?

Looking at the datasheet - bits are set in IOCxP and IOCxN for rising and falling edge interrupts - both to detect both.

I added an IOC interrupt to a chart and selected some pins (the 'selection' image is too small - and I couldn't find keys to enlarge it) - then looking at the code generated:

Code: Select all

  // Interrupt
  st_bit(INTCON,GIE);
  IOCAP=0x28;
  IOCAN=0x18;
  IOCCP=0x0;
  IOCCN=0x0;
  st_bit(PIE0, IOCIE);

Which looks okay?

Martin

[DirkB]

Hi Martin,

these are exactly the entries (C code) in my interrupt handler. It works with other chips such as the 16F1825/27, the 18F14K22, and many others as well. You have to use a chip. In the simulation, it almost always works, even if it doesn't work on the chip.

[mnfisher]

I don't have that part to test with - sorry.
As a simple 'thought experiment' - can you add code to set the interrupt pins as 'inputs' before the interrupt icon? (set TRISA or use read a pin using input)
Set the pins to be 'digital' (set ANSELA)
Add a simple ISR that toggles a different pin.
Add a signal and let us know how the results look..

It's a long shot that the default values are different on this MCU for some reason?

Martin

[mnfisher]

Also to check that you are not trying to use a switch and just seeing 'bounce'?

[DirkB]

I don't have a switch; it's a reflex coupler. It has a low slew rate. That's why I've configured the input pin as an input and set it to smittrigger using TRISA = 0b001100; and INLVLA = 0b001100;. The positive edge and both edges work, but the negative edge doesn't work. It behaves the same as if both edges were triggered simultaneously. This also affects the PIC16F18426, and probably a few others. The PIC16F1825, for example, works absolutely flawlessly. According to the datasheet, the entries are correct. Are these entries processed and compiled correctly by FC?

thanks

[mnfisher]

Sorry - I'm not sure I follow - "negative edge behaves as if both edges are triggered"? Is this a limitation of the MCU (the same ISR is called for rising, falling and both - although this would usually(always?) be the case)
Please can you post a code snippet that demonstrates - this and the 'desired' results (or the other MCU results)?

The code generated is slightly 'odd'?

Code: Select all

void MX_INTERRUPT_MACRO(void)
{

  //Handler code for [IOC0]
  #ifndef MX_INTHANDLER_INTCON_IOCIF
  #define MX_INTHANDLER_INTCON_IOCIF
  char mxtmp;
  if (ts_bit(PIR0, IOCIF) && ts_bit(PIE0, IOCIE))
  {
      FCM_isr();                // Call the ISR
      mxtmp=PORTA;	     // What does this achieve?
      mxtmp=PORTC;        // What does this do?
      cr_bit(PIR0, IOCIF);  ;// Clear the 'change' interrupt flag
      IOCAF=0;                   // Clear the individual 'pin' flag
      IOCCF=0;
  }

I'm not sure what mxtmp is used for here (read the values of PORTA and PORTC - but why?)

An issue with the 'interrupt' block handler - the pin diagram is to small and the masks don't change when selecting pins (although clicking the 'select' arrow again shows the values)


Martin

[BenR]

Hello,

Regarding this.

I'm not sure what mxtmp is used for here (read the values of PORTA and PORTC - but why?)

You have to read the Port register to effectively rearm the interrupt. Otherwise it won't interrupt again assuming your not reading the port register somewhere else in your code. So we force the issue to be resolved by silently reading the associated port registers.

I'll investigate the masks and why they are not behaiving correctly.

[BenR]

Port selection looks ok to me in v11.

PortSelectInt.jpg (57.36 KiB) Viewed 79 times

[mnfisher]

Thanks Ben - that explains the read of the port registers.

I still have the odd layout - with the masks as 0 (until I minimise the select pin(s) diagram)

ISR.jpg (32.66 KiB) Viewed 16 times

Martin