* [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s @ 2012-08-22 7:27 Bob Brusa 2012-08-27 19:31 ` Michael Bergandi 0 siblings, 1 reply; 4+ messages in thread From: Bob Brusa @ 2012-08-22 7:27 UTC (permalink / raw) To: discuss ecos Hi, I use an ISR that has considerable work to. Clearly, a job for a dsr, but I found, that using a dsr is too time consuming, so I must do everything in the isr (A screenshot of the ISR is available here: https://dl.dropbox.com/u/13412634/Screenshot%20-%2021.08.jpg) The ISR handles 4 pwm channels - all producing interrupts at a rate of 1 ms. 3 of the channels run syncronously and hence only one of them has interrupts enabled. The 4th channels also triggers interrupts every ms, but is not in phase with the other 3 channels. The pwm interrupts have lowest priority of all interrupts in my system. Upon entry in the pwm_isr, I clear flags, mask the interrupt of the pwm-hardware on the level of the interrupt controller (AIC) and enable interrupts again. This should allow higher priority interrupts to come through, but no pwm interrupts while the pwm_isr is busy. This according to my understanding. But it is obviously wrong, because the primitve "semaphore" I implemented tells me, that a 2nd pwm interrupt interrupts the first one. One explanation I have for this is, that one of the higher priority interrupts clears the interrupt mask of the pwm channels - which I would consider a bug of eCos. Onother explanation could be, that the system timer interrupts the pwm_isr and runs a task and of course, many threads in my system access globals of the pwm_isr, doing this within mask-pwm-interrupts/unmask-pwm-interrupts brackets. But it would surprise me that ecos runs a thread while an isr is still unfinished. Any comments? Bob -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s 2012-08-22 7:27 [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s Bob Brusa @ 2012-08-27 19:31 ` Michael Bergandi 2012-08-27 19:55 ` Bob Brusa 0 siblings, 1 reply; 4+ messages in thread From: Michael Bergandi @ 2012-08-27 19:31 UTC (permalink / raw) To: Bob Brusa; +Cc: discuss ecos Bob, > I use an ISR that has considerable work to. Clearly, a job for a dsr, but I > found, that using a dsr is too time consuming, so I must do everything in > the isr (A screenshot of the ISR is available here: > https://dl.dropbox.com/u/13412634/Screenshot%20-%2021.08.jpg) The ISR doesn't look that big to me really. To get a real idea of how long your ISR is taking, you can just time it. If you have the memory you can simply accumulate the timing in a buffer and print them out later to look for abnormalities. > The ISR handles 4 pwm channels - all producing interrupts at a rate of 1 ms. > 3 of the channels run syncronously and hence only one of them has interrupts > enabled. The 4th channels also triggers interrupts every ms, but is not in > phase with the other 3 channels. The pwm interrupts have lowest priority of > all interrupts in my system. Ok, there may be an issue here. Considering that they are the lowest priority, anything and everything else in the system can put them off causing you to miss an interrupt from the PWM. The timings as described above can give you some insight into that. > Upon entry in the pwm_isr, I clear flags, mask the interrupt of the > pwm-hardware on the level of the interrupt controller (AIC) and enable > interrupts again. This should allow higher priority interrupts to come > through, but no pwm interrupts while the pwm_isr is busy. This according to > my understanding. But it is obviously wrong, because the primitve > "semaphore" I implemented tells me, that a 2nd pwm interrupt interrupts the > first one. First, remove the HAL_ENABLE_INTERRUPTS macro from the ISR. That is not needed and may be causing problems. That call enables the system interrupt controller. HAL interrupts are obviously enabled if you got into the ISR to begin with. Next, you should mask the interrupt, then acknowledge it. If you use a DSR, then unmask at the end of the DSR. Now, be absolutely certain that all pwm channel vectors are set to the same priority (even the one's you THINK aren't enabled). Sounds to me like one of them is enabled and shouldn't be and has a higher priority. For example, you have: if (pwm_isr & 7) then the ISR was triggered by pwm0, which is synchronous with pwm1 and pwm2 Well, if ((pwm_isr & 6) != 0) then pwm1 or pwm2 is generating interrupts and one of them is probably a higher priority than the others. > One explanation I have for this is, that one of the higher priority > interrupts clears the interrupt mask of the pwm channels - which I would > consider a bug of eCos. Probably unlikely. > Onother explanation could be, that the system timer interrupts the pwm_isr > and runs a task and of course, many threads in my system access globals of > the pwm_isr, doing this within mask-pwm-interrupts/unmask-pwm-interrupts > brackets. But it would surprise me that ecos runs a thread while an isr is > still unfinished. Any comments? eCos will not run a task while an ISR or DSR is executing. Hope this helps you along. -- Mike -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s 2012-08-27 19:31 ` Michael Bergandi @ 2012-08-27 19:55 ` Bob Brusa 0 siblings, 0 replies; 4+ messages in thread From: Bob Brusa @ 2012-08-27 19:55 UTC (permalink / raw) To: Michael Bergandi; +Cc: discuss ecos Am 27.08.2012 21:30, schrieb Michael Bergandi: > Bob, > >> I use an ISR that has considerable work to. Clearly, a job for a dsr, but I >> found, that using a dsr is too time consuming, so I must do everything in >> the isr (A screenshot of the ISR is available here: >> https://dl.dropbox.com/u/13412634/Screenshot%20-%2021.08.jpg) > > The ISR doesn't look that big to me really. To get a real idea of how > long your ISR is taking, you can just time it. If you have the memory > you can simply accumulate the timing in a buffer and print them out > later to look for abnormalities. > >> The ISR handles 4 pwm channels - all producing interrupts at a rate of 1 ms. >> 3 of the channels run syncronously and hence only one of them has interrupts >> enabled. The 4th channels also triggers interrupts every ms, but is not in >> phase with the other 3 channels. The pwm interrupts have lowest priority of >> all interrupts in my system. > > Ok, there may be an issue here. Considering that they are the lowest > priority, anything and everything else in the system can put them off > causing you to miss an interrupt from the PWM. The timings as > described above can give you some insight into that. > >> Upon entry in the pwm_isr, I clear flags, mask the interrupt of the >> pwm-hardware on the level of the interrupt controller (AIC) and enable >> interrupts again. This should allow higher priority interrupts to come >> through, but no pwm interrupts while the pwm_isr is busy. This according to >> my understanding. But it is obviously wrong, because the primitve >> "semaphore" I implemented tells me, that a 2nd pwm interrupt interrupts the >> first one. > > First, remove the HAL_ENABLE_INTERRUPTS macro from the ISR. That is > not needed and may be causing problems. That call enables the system > interrupt controller. HAL interrupts are obviously enabled if you got > into the ISR to begin with. > > Next, you should mask the interrupt, then acknowledge it. If you use a > DSR, then unmask at the end of the DSR. > > Now, be absolutely certain that all pwm channel vectors are set to the > same priority (even the one's you THINK aren't enabled). Sounds to me > like one of them is enabled and shouldn't be and has a higher > priority. For example, you have: > > if (pwm_isr & 7) then the ISR was triggered by pwm0, which is > synchronous with pwm1 and pwm2 > > Well, > > if ((pwm_isr & 6) != 0) then pwm1 or pwm2 is generating interrupts and > one of them is probably a higher priority than the others. > > >> One explanation I have for this is, that one of the higher priority >> interrupts clears the interrupt mask of the pwm channels - which I would >> consider a bug of eCos. > > Probably unlikely. > >> Onother explanation could be, that the system timer interrupts the pwm_isr >> and runs a task and of course, many threads in my system access globals of >> the pwm_isr, doing this within mask-pwm-interrupts/unmask-pwm-interrupts >> brackets. But it would surprise me that ecos runs a thread while an isr is >> still unfinished. Any comments? > > eCos will not run a task while an ISR or DSR is executing. > > Hope this helps you along. > Michael, you wrote: First, remove the HAL_ENABLE_INTERRUPTS macro from the ISR. That is not needed and may be causing problems. That call enables the system interrupt controller. HAL interrupts are obviously enabled if you got into the ISR to begin with. But if I do this, even higher priority interrupts are no longer allowed to come through. But I need them - otherwize I might loose characters during io-operations. Yes, I am sure that only pwm3 and pwm0 generate interrupts. The AT91SAM7s ores all pwm-interrupt together and assigns them to vectored interrupt 10. What I need is 1 pwm-interrupt 10 is blocked while its isr is running 2 interrupts of higher priority come through 3 pwm interrupts that happen while the pwm_isr is busy are defered and as soon as I return from the pwm_isr, such a possibly pending new pwm_interrupt should invoke pwm_isr again. I have the impression, that I got something wrong with the sequence of eCos-calls in the pwm_isr. Caling them in proper sequence would probalby achieve the desired result. Any further comments? Thanks and regards - Bob -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <CAOHvnTNSNzD0G+QMAv+B2+ZpRgwwCm5+7oQ+ArXXn-t_VJ6t=g@mail.gmail.com>]
* Re: [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s [not found] <CAOHvnTNSNzD0G+QMAv+B2+ZpRgwwCm5+7oQ+ArXXn-t_VJ6t=g@mail.gmail.com> @ 2012-08-30 13:37 ` Bob Brusa 0 siblings, 0 replies; 4+ messages in thread From: Bob Brusa @ 2012-08-30 13:37 UTC (permalink / raw) To: ecos discuss -------- Original-Nachricht -------- Betreff: Re: [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s Datum: Mon, 27 Aug 2012 16:22:10 -0400 Von: Michael Bergandi <mbergandi@gmail.com> An: Bob Brusa <bob.brusa@gmail.com> Bob, > you wrote: > First, remove the HAL_ENABLE_INTERRUPTS macro from the ISR. That is > not needed and may be causing problems. That call enables the system > interrupt controller. HAL interrupts are obviously enabled if you got > into the ISR to begin with. > > But if I do this, even higher priority interrupts are no longer allowed to > come through. But I need them - otherwize I might loose characters during > io-operations. I think it is safe to assume that HAL (Global) interrupts were enabled prior to your pwm interrupt happing or your pwm_isr would not run. [yes] Hence, HAL interrupts were enabled before the pwm interrupt happend and the pwm ISR was called and should remain enabled unless you explicitly disabled them. I don't see any reason or way that HAL interrupts would/could be disabled. [I understood from the eCos-doc that an isr is called with i-off (global) - one has to re-enable interrupts explicitely to allow higher priority interrupts to come through. Do I get something wrong?] cyg_interrupt_mask(vector), where vector is 10 for the pwm will only mask the pwm interrupt. [That's what I would expect, but I get pwm_interrupts while the pwm_isr is still busy. And when I check the Mask register, I find it is masked - but the 2nd interrupt is here. I do not grasp what's going on.] HAL interrupts are unaffected. > Yes, I am sure that only pwm3 and pwm0 generate interrupts. The AT91SAM7s > ores all pwm-interrupt together and assigns them to vectored interrupt 10. Ok, then they should all be at the same priority level, since it is a one to one relationship between priority and vector. [Yes, same priority] > What I need is > 1 pwm-interrupt 10 is blocked while its isr is running cyg_interrupt_mask() should do that for you. [would be nice - but see above] > 2 interrupts of higher priority come through Provided that HAL interrupts are not explicitly disabled, that should be naturally occurring. [not according to my unterstanding of the eCos doc - see above] > 3 pwm interrupts that happen while the pwm_isr is busy are defered and > as soon as I return from the pwm_isr, such a possibly pending new > pwm_interrupt should invoke pwm_isr again. cyg_interrupt_mask() followed immediately by cyg_interrupt_acknowledge() should provide that. If the interrupt is masked, and another occurs, the interrupt bit will be set again since the acknowledgement and when the cyg_interrupt_unmask() is called another interrupt should occur. Another option is to check the interrupt flag at the end of the first processing run to see if another one is pending. If so, then go ahead and service it too and save yourself the context switching overhead. > I have the impression, that I got something wrong with the sequence of > eCos-calls in the pwm_isr. Caling them in proper sequence would probalby > achieve the desired result. Certainly wouldn't hurt. > Any further comments? Thanks and regards - Bob I just thought of one other possibility and it goes against something I said last time. IIRC, it IS possible for ecos to pre-empt an ISR to run a task if that ISR is set at a lower priority than ecos naturally runs at. eCos commonly runs at priority 8 on many platforms. This is probably worth checking. -- Mike Hi Mike, as you see, I addressed this mail (again) to ecos discuss instead of keeping it private. I feel the subject is of broader interest. Anyway, you should receive a copy because you have registered for the discussion.... Why broader interest? Well, the fact that a specific peripheral interrupt comes through while it is masked does not correspond to expectations. Who is to blame? eCos or the AIC of the AT91SAM7s? I do not know yet. Furthermore, I just run into another problem with spuious interrupts. Configtool allows to build a library that ignores or not ignores spurious interrupts. I tried both - no change, I still have spurious interrupts. Not often, but one is enough to kill the system. Then I have a few comments on your comments - see above, they are interspersed in your text and enclosed in square brakets. Thanks - Bob -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-08-30 13:37 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-22 7:27 [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s Bob Brusa 2012-08-27 19:31 ` Michael Bergandi 2012-08-27 19:55 ` Bob Brusa [not found] <CAOHvnTNSNzD0G+QMAv+B2+ZpRgwwCm5+7oQ+ArXXn-t_VJ6t=g@mail.gmail.com> 2012-08-30 13:37 ` Bob Brusa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).