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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

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

跳至解决方案
1,260 次查看
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?

标签 (1)
0 项奖励
1 解答
974 次查看
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 项奖励
8 回复数
974 次查看
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 项奖励
974 次查看
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 项奖励
974 次查看
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 项奖励
974 次查看
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 项奖励
975 次查看
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 项奖励
974 次查看
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 项奖励
974 次查看
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 项奖励
974 次查看
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 项奖励