Re: [ECOS] Interrupt handling under eCOS for the arm AT91SAM7s

[Bob Brusa <bob.brusa@gmail.com>]

-------- 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