What could cause an Interrupt Flag to not be set on every interrupt edge?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

What could cause an Interrupt Flag to not be set on every interrupt edge?

Jump to solution
1,165 Views
video_man
Contributor III

I'm using Port B interrupts on a MC9S08DZ128. The interrupt pin is set for Edge only and is always enabled. Sometimes the interrupt flag (PTBIF) is not getting set (PTBIF read with the debugger as well as my code not getting an interrupt) even though I can see the level change on the Port B pin with an oscilloscope and also read the level change in the PTBD register with the debugger. The problem seems to be random with some interrupts flagged and others not.

 

I thought PTBIF would ALWAYS be set even if another interrupt was being processed, or another interrupt occurred at the same time (for instance a timer interrupt). What could cause the PTBIF bit to not get set?

Labels (1)
0 Kudos
1 Solution
879 Views
kef2
Senior Contributor IV
  • The diagram is how I understood the system to work. According to the diagram an edge on any interrupt enabled pin of the port at any time will set the latch(or it remains set if already set). So how can an edge occur at a pin but the latch is not set after the edge occurs? It can't.

No. An edge on any 1 out of 8 port pins will set the latch, provided other 7 out of 8 pins are at not active level. Latch is single and common for all 8 PORTB pins. Only one simultaneous edge event can be reliably registered. You should treat PORTB interrupt like single interrupt pin with additional OR 8 gate with programmable inverters and AND 2 disablers on each input. This thing is not equivalent to 8 interrupt inputs.

View solution in original post

0 Kudos
8 Replies
879 Views
rsdio
Contributor II

I have seen this issue with processors from other manufacturers. Although "edge-triggered" implies that there is hardware like a Schmitt-triggered flip-flop that will catch and hold any edge, in many cases there is nothing but a microcode-polled bit. If the pulse width is too narrow, the polling will miss the edge. These other processors have a specification in the data sheet telling the minimum pulse width in terms of clock period. I have not looked through the MC9S08DZ128 data sheet, but you might search for something like that in the electrical section.

Also, you may be seeing random results because of the phase alignment of your external interrupt signal versus the internal processor clock. Sometimes the polling will catch the narrow pulse when it is high, other times it will poll just before it goes high and again after it returns low, completely missing the high state.

0 Kudos
879 Views
video_man
Contributor III

Thanks for the replies, but the interrupt "pulse" width can't be too short. The interrupt (high to low transition) from the source stays low until it is cleared via i2c command from the processor. i.e. it goes low and stays low because the uP doesn't set the PTBIF flag and so the interrupt doesn't get serviced. My workaround is to test the interrupt pin to see if it is low, either by periodically polling the pin level (not the PTBIF flag which doesn't get set) or by testing the pin level when an interrupt from another "related" source occurs.

But I still don't know why the uP sometimes misses the interrupt edges. I thought the interrupt edge was detected entirely in the pin hardware and sets PTBIF in hardware, so that other interrupts occurring at the same time couldn't cause the processor to miss an interrupt edge. But I suppose if more than one interrupt occurs on several Port B pins at nearly the same time (which is true in my case) the software could be clearing PTBIF from the interrupt on one pin while the hardware was trying to set PTBIF from the interrupt on another pin. Could that cause PTBIF to not get set on the 2nd interrupt, or is there something in the uP to prevent that from happening? That could explain why the missed interrupts are random.

0 Kudos
879 Views
kef2
Senior Contributor IV

I thought you used single PORTB interrupt pin. This changes things a lot. If you look at picture in 6.3 Pin Interrupts chapter, you will notice single D latch for all 8 PORTx interrupt pins! No wonder you can't detect reliably each active edge on each PORTB interrupt pin.

0 Kudos
879 Views
video_man
Contributor III

The diagram is how I understood the system to work. According to the diagram an edge on any interrupt enabled pin of the port at any time will set the latch (or it remains set if already set). So how can an edge occur at a pin but the latch is not set after the edge occurs? It can't.

But my assumption that PTBIF was never set may be wrong. Perhaps this is also what you are thinking? Two interrupt edges (pin 1 and then pin 2) both occur before PTBIF is cleared in response to the interrupt request created by pin 1, but my interrupt handler has already tested pin 2 before the second pin 2 interrupt edge arrived. Hence, the interrupt from pin 1 is processed, but the interrupt from pin 2 is not processed (and therefore the pin 2 source is not cleared leaving pin 2 low indefinitely). That fits what I see. When I halt the debugger pin 2 is low, PTBIF is not set (appears that the pin 2 interrupt was missed), and the pin 2 interrupt routine was not executed.


So this may be a silly logical error in my interrupt handler, which is a little complex because I use 21 Port A, Port B, and Port D interrupt pins.

0 Kudos
880 Views
kef2
Senior Contributor IV
  • The diagram is how I understood the system to work. According to the diagram an edge on any interrupt enabled pin of the port at any time will set the latch(or it remains set if already set). So how can an edge occur at a pin but the latch is not set after the edge occurs? It can't.

No. An edge on any 1 out of 8 port pins will set the latch, provided other 7 out of 8 pins are at not active level. Latch is single and common for all 8 PORTB pins. Only one simultaneous edge event can be reliably registered. You should treat PORTB interrupt like single interrupt pin with additional OR 8 gate with programmable inverters and AND 2 disablers on each input. This thing is not equivalent to 8 interrupt inputs.

0 Kudos
879 Views
video_man
Contributor III

  • No. An edge on any 1 out of 8 port pins will set the latch, provided other 7 out of 8 pins are at not active level.

Yes, obviously. Thank you. I looked at the 8-input OR gate and only thinking about edges it seemed to validate my erroneous preconceived notion that an edge on any pin should always set the PTBIF latch. I totally blanked that if the pin remained at the active level after the edge it would mask edges from all other pins. Those "erroneous preconceived notions" can sure make one stupid.

That answers my original question and I now see what I need to do to make my interrupt system work. Thanks again.

0 Kudos
879 Views
kef2
Senior Contributor IV

Perhaps it is set, but CPU is late servicing previous interrupt flag=1 event? Try lowering pulse frequency and see if it helps.

If not, then perhaps pulse is too short. Should be longer than bus clock period.

0 Kudos
879 Views
video_man
Contributor III

The interrupt can't be too narrow because it goes low at the pin and stays low indefinitely because it is never serviced by the uP. See my reply below for more detail.

PTBIF appears to not be set by the interrupt. I look at the PTBIF bit with the debugger and it is not set even though the level on the pin has gone low and stayed low. I check the pin level with both an oscilloscope and from the debugger after the pin goes low.

0 Kudos