[ECOS] Interrupt handling under eCOS for the arm AT91SAM7s

Michael Bergandi mbergandi@gmail.com
Mon Aug 27 19:31:00 GMT 2012


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



More information about the Ecos-discuss mailing list