EmbeddedRelated.com
Forums

One of the 200 interrupts does not get executed sometimes due to a single statement

Started by karthikbg December 14, 2006
karthikbg wrote:

> Hi, > > 1) I have 200 interrupts and the corresponding Interrupt service > routines for those. > > ISR () > { > If (INTERRUPT_FLAG == 1) > DO_ISR_ACTIVITY > INTERRUPT_FLAG = 0; > } > > When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the > interrupt gets fired, but not handled as it is at the end of ISR. How > to avoid this. > But, the clearing of the 'INTERRUPT_FLAG = 0' is required. > > So, one of the 200 interrupts does not get executed sometimes. > How to avoid the above problem ?
This is the classic shared data problem. The solution is to ensure the INTERRUPT_FLAG = 0; operation is atomic i.e cannot be interrupted once started. There are two ways to do this. The first is to use an atomic microprocessor instruction rather than a C statement which might consist of several microprocessor instructions. The second is to disable interrupts just before clearing the flag and enable them immediately after. The first method is preferable IMV.
> > 2) Further, i do suspect that an interrupt can come in the middle of > 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that > interrupt being left un-attended. > If this is the case, how to check this as there are 200 interrupts ? >
Depends on the micro. Some will store the fact the interrupt occurred and service it next time interrupts are enabled. Others will just ignore and lose it. This is why the first rule of real time is keep interrupt routines as short as possible.Think about moving some of the functionality of the ISR out into the background. Ian
karthikbg wrote:

> Hi, > > 1) I have 200 interrupts and the corresponding Interrupt service > routines for those. > > ISR () > { > If (INTERRUPT_FLAG == 1) > DO_ISR_ACTIVITY > INTERRUPT_FLAG = 0; > } > > When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the > interrupt gets fired, but not handled as it is at the end of ISR. How > to avoid this. > But, the clearing of the 'INTERRUPT_FLAG = 0' is required. > > So, one of the 200 interrupts does not get executed sometimes. > How to avoid the above problem ? > > 2) Further, i do suspect that an interrupt can come in the middle of > 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that > interrupt being left un-attended. > If this is the case, how to check this as there are 200 interrupts ? > > Tonnes of Thx in advans, > Karthik Balaguru
Without hardware information its impossible to answer. On most processors the isr is entered because the interrupt flag has been set so there is no requirement to check it again. If you clear the flag at the start of the isr then you wont miss an interrupt that occurs during the isr, the hardware will just rerun the isr. You would miss then if there were 2 or more occuring. Correctly prioritising will solve most problems. Later in this thread you mention software interrupts, you cannot get this sort of problem with those as their code generated.
cbarn24050@aol.com wrote:
> karthikbg wrote: > > > Hi, > > > > 1) I have 200 interrupts and the corresponding Interrupt service > > routines for those. > > > > ISR () > > { > > If (INTERRUPT_FLAG == 1) > > DO_ISR_ACTIVITY > > INTERRUPT_FLAG = 0; > > } > > > > When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the > > interrupt gets fired, but not handled as it is at the end of ISR. How > > to avoid this. > > But, the clearing of the 'INTERRUPT_FLAG = 0' is required. > > > > So, one of the 200 interrupts does not get executed sometimes. > > How to avoid the above problem ? > > > > 2) Further, i do suspect that an interrupt can come in the middle of > > 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that > > interrupt being left un-attended. > > If this is the case, how to check this as there are 200 interrupts ? > > > > Tonnes of Thx in advans, > > Karthik Balaguru > > Without hardware information its impossible to answer. On most > processors the isr is entered because the interrupt flag has been set > so there is no requirement to check it again. If you clear the flag at > the start of the isr then you wont miss an interrupt that occurs during > the isr, the hardware will just rerun the isr. You would miss then if > there were 2 or more occuring. Correctly prioritising will solve most > problems. Later in this thread you mention software interrupts, you > cannot get this sort of problem with those as their code generated.
I am using Vxworks with PowerPC. I Need to handle interrupts that may occur when the other interrupt is being handled.(Nested Interrupts). I find that sometimes , one of the interrupt gets lost and the corresponding alarm gets generated as that interrupt got skipped off. Regards, Karthik Balaguru
"FreeRTOS.org" <non.given@hotmail.con> wrote in message 
news:hxfgh.16138$k74.5542@text.news.blueyonder.co.uk...
> > "Rufus V. Smith" <nospam@nospam.com> wrote in message > news:45817976$0$20219$88260bb3@news.teranews.com... >> >> "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message >> news:1166104313.478604.162220@f1g2000cwa.googlegroups.com... >>> >>> karthikbg wrote: >>> >>>> Hi, >>>> >>>> 1) I have 200 interrupts and the corresponding Interrupt service >>>> routines for those. >>>> >>>> ISR () >>>> { >>>> If (INTERRUPT_FLAG == 1) >>>> DO_ISR_ACTIVITY >>>> INTERRUPT_FLAG = 0; >>>> } >>>> >>>> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the >>>> interrupt gets fired, but not handled as it is at the end of ISR. How >>>> to avoid this. >>>> But, the clearing of the 'INTERRUPT_FLAG = 0' is required. >>>> >>>> So, one of the 200 interrupts does not get executed sometimes. >>>> How to avoid the above problem ? >>>> >>>> 2) Further, i do suspect that an interrupt can come in the middle of >>>> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that >>>> interrupt being left un-attended. >>>> If this is the case, how to check this as there are 200 interrupts ? >>> >>> How about something like this: >>> >>> ISR() >>> { >>> if( interrupt_flag ) >>> { >>> interrupt_flag = 0; >>> do_isr_activity(); >>> } >>> } >>> >>> That way, when a new interrupt comes in while you're processing the old >>> one, the interrupt flag will be set again. This assumes >>> 'do_isr_activity()' can handle the case where multiple interrupts have >>> been received. >>> >> >> This will handle receiving multiple interrupts >> during interrupt processing. >> >> ISR() >> { >> static int unhandled = 0; >> >> if (unhandled) >> { >> unhandled++; // buffering interrupt counts >> interrupt_flag = 0; >> } >> else >> { >> unhandled++; // first interrupt >> interrupt_flag = 0; >> while (unhandled) // handle interrupt, and others that may come in >> { >> do_isr_activity(); >> unhandled--; >> } >> } >> } >> >> Rufus >> > > > Reading and writing unhandled in a nested interrupt? Is write access > atomic? >
I make the assumption here that increments/decrements/tests of int's are atomic. Perhaps a comment to that effect should be added to alert a developer for whom this is not the case.
"Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message 
news:1166118135.807907.291650@j72g2000cwa.googlegroups.com...
> > Rufus V. Smith wrote: > >> "Arlet" <usenet+5@ladybug.xs4all.nl> wrote in message >> news:1166104313.478604.162220@f1g2000cwa.googlegroups.com... >> > >> > karthikbg wrote: >> > >> >> Hi, >> >> >> >> 1) I have 200 interrupts and the corresponding Interrupt service >> >> routines for those. >> >> >> >> ISR () >> >> { >> >> If (INTERRUPT_FLAG == 1) >> >> DO_ISR_ACTIVITY >> >> INTERRUPT_FLAG = 0; >> >> } >> >> >> >> When i am doing the 'INTERRUPT_FLAG=0' in the above code, One of the >> >> interrupt gets fired, but not handled as it is at the end of ISR. How >> >> to avoid this. >> >> But, the clearing of the 'INTERRUPT_FLAG = 0' is required. >> >> >> >> So, one of the 200 interrupts does not get executed sometimes. >> >> How to avoid the above problem ? >> >> >> >> 2) Further, i do suspect that an interrupt can come in the middle of >> >> 'DO_ISR_ACTIVITY' routine and that can also cause a problem of that >> >> interrupt being left un-attended. >> >> If this is the case, how to check this as there are 200 interrupts ? >> > >> > How about something like this: >> > >> > ISR() >> > { >> > if( interrupt_flag ) >> > { >> > interrupt_flag = 0; >> > do_isr_activity(); >> > } >> > } >> > >> > That way, when a new interrupt comes in while you're processing the old >> > one, the interrupt flag will be set again. This assumes >> > 'do_isr_activity()' can handle the case where multiple interrupts have >> > been received. >> > >> >> This will handle receiving multiple interrupts >> during interrupt processing. >> >> ISR() >> { >> static int unhandled = 0; >> >> if (unhandled) >> { >> unhandled++; // buffering interrupt counts >> interrupt_flag = 0; >> } >> else >> { >> unhandled++; // first interrupt >> interrupt_flag = 0; >> while (unhandled) // handle interrupt, and others that may come >> in >> { >> do_isr_activity(); >> unhandled--; >> } >> } >> } >> >> Rufus > > Usually, the ISR isn't reentrant, as it disables any further > interrupts, so this wouldn't do anything. > > I was referring to a situation where there are many h/w interrupts, but > where it was okay to occasionally miss one, for instance if the > peripheral has a FIFO. > > If every interrupt is important, the OP needs to make sure the ISR is > finished before the next interrupt is received. >
Oh, I thought interrupt_flag = 0; effectively would re-enable that interrupt, so the routine could possibly be re-entered at that point, just counting and re-enabling. Rufus