This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Re: ISR not causing an DSR in some rare conditions
Hi,
No. The interrupts will not be disabled at any time. The interrupt
from
this source will only be acknowledged in the isr function.
The functionality is simple. A hardware unit will be started and
reports the finish with an interrupt. I have made a counter on
hardware unit start, isr and dsr. After this long-run test, the dsr
counter is one less than the other counters.
[...]
Thus, you need to increment your test counter by the value of 'count'
argument in the DSR handler, do you?
No... you don't understand.
Well, maybe, but that's how I read your:
No. The interrupts will not be disabled at any time. The interrupt
from
this source will only be acknowledged in the isr function.
If interrupts are not disabled, and interrupt is acked in isr function
as you wrote above, then more than one could happen while no dsr is run
yet.
The dsr count of this particular irq cannot be other than 1.
Well, seems I indeed misunderstand, but did you *actually* check it
isn't? Ah, well, from your other reply I see you didn't, though I'd
check anyway as "cannot" and "doesn't indeed happen" are surprisingly
different, at least in my experience.
Maybe i was not clear in my descriptions. I'll try to go in more detail.
The XScale is using a picture scaler in an FPGA (so outside of the
processor). It will setup the scaler and start it. The irq tells the system
the scaling has finished. Now in the dsr function a new scaler setup is
loaded and the scaler is restarted. That's way only one irq,dsr will come.
You're right, that i did not check the dsr count, but there's no
possibility for multiple dsr's. What i see is that my scaling stops after a
long time and from what i found out, it's the missing dsr, because the
expected isr was there.
The hardware unit causes only one irq some time after it was
started. If ecos does not call the dsr routine, the hardware unit will
not be started again and so no more irq's will be caused.
Do you say that it's DSR that restarts the hardware unit? Seems so
though you didn't tell it to us before.
Sorry... i hope now it's more clear.
After DSR is missed is the entire system operational? I mean is the rest
of the system running OK (including ISRs/DSRs from other sources,
e.g., timer) after the DSR is missing? If so, then it looks like some
race somewhere, either in your code or in the eCos, or entirely
independent bug that just happens to break this thing.
The entire system is working well. Other irqs/dsrs are working and
multithreading too. For me it looks like a race condition, maybe not in
ecos itself, but in a platform/variant implementation. I had the "feeling"
that the system sometimes "loses" dsrs before with the dma channels, but
currently i'm using multiple dma channels at the same time, so multiple
irqs will happen and if a dsrs is missing, another irq will retry the dsr.
I plan to setup a test with a bit hardware support (FPGA generate multiple
irqs in a short time)
BTW, if it runs on ARM, do you use FIQ? I think I know at least 2 bugs
in the ARM HAL, one of which is with FIQ handling (and another one being
in the context switch), but chances are very low they show themselves
the way you see.
No. From what i know the current pxa2x0 variant does not support FIQ's, so
i don't use them. For my understanding, the IRQ's are okay only the
IRQ->DSR functionality isn't working.
For now i've implemented a watchdog to check for the missing dsr, which
"fixes" the problem, but my company is starting a new project and we are
not sure if we should continue using ecos. I like it, but the DSR problems
are critical. I also had problems with very long delays between ISR and
DSR, which maybe caused by the execution order.
Bye...
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss