* [ECOS] Fwd: Re: [ECOS] contents of the table " hal_interrupt_handlers" arm7 processor
[not found] <5051FD4B.7070105@gmail.com>
@ 2012-09-13 16:20 ` Bob Brusa
0 siblings, 0 replies; only message in thread
From: Bob Brusa @ 2012-09-13 16:20 UTC (permalink / raw)
To: ecos discuss
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
-------- Original-Nachricht --------
Betreff: Re: [ECOS] contents of the table " hal_interrupt_handlers" arm7
processor
Datum: Thu, 13 Sep 2012 17:35:39 +0200
Von: Bob Brusa <bob.brusa@gmail.com>
An: Michael Bergandi <mbergandi@gmail.com>
Am 12.09.2012 22:11, schrieb Michael Bergandi:
> Bob,
>
>> I find, that the jump bne 10f is always executed and subsequently, the
>> correct handler is fetched from the table hal_interrupt_handlers. But hellas
>> - when I get my "spurious interrupt" I find that the interrupt source is
>> correct (10 for pwm), the datapointer however is zero und all entries in the
>> hal_interrupt_handlers table are filled with the address of the
>> hal_default_isr.
>
> This sounds like it is working correctly. An interrupt occurred, it found
> the handler and called it.
>
>
>
>> I would expect the table hal_interrupt_handlers to be initialized during
>> system startup. But obviously, this assumption is wrong. Which part of eCOS
>> (dynamically) modifies this table and why??
>> Thanks for help and advice....Bob
>
> hal_interrupt_handers is initialized at startup with hal_default_isr (which
> does nothing).
>
> A driver using interrupts would create an ISR and DSR (if required) and call
> cyg_drv_interrupt_create(). The handle returned by
> cyg_drv_interrupt_create() would then be used in the call to
> cyg_drv_interrupt_attach() to attach the interrupt to the hardware vector
> which places it in the hal_interrupt_handers table.
>
> --
> Mike
>
>
>
Hi Mike,
I found that all my previous findings were scrap - caused by a system
that had gone wild. The problem was the handling of the interrupt enable
and eoi in the pwm_isr.
In a way, the whole affair is a nice example for Murphys law: Read
instructions and this I finally did, although it was rather time
consuming :-)
The revised pwm_isr is attached - and with this isr, no more spurious
interrupts!
Thanks for help and best regards - Bob
[-- Attachment #2: pwm_isr.c --]
[-- Type: text/plain, Size: 1428 bytes --]
static uint32_t pwm_isr(cyg_vector_t vector, cyg_addrword_t data)
{
static uint32_t pwmisr, icnt;
CYG_INTERRUPT_STATE istate;
CYG_ASSERT (CYGNUM_HAL_INTERRUPT_PWMC == vector, "Wrong interrupts");
pwms_idisable; // mask pwm interrupts
HAL_READ_UINT32(AT91_PWM + AT91_PWM_ISR, pwmisr); // clears pwm-interrupt
HAL_QUERY_INTERRUPTS(istate); // supervisor mode - interrupts are disabled
HAL_ENABLE_INTERRUPTS(); // turn them on to allow higher priority irs
icnt++; // to come through
while (pwmisr) {
if (icnt == 1) {
if (pwmisr & 7) { // pwm0..2 run synchroneously, hence only pwm0 has been set for interrupts
Set_LEDs();
Chk_Keys(); // Check if any key is pressed
}
if (pwmisr & 8) { // pwm3 interrupt
pwm3d.ticks++;
Read_AT91adc();
Do_Scan();
} // end pwm3 interrupt
} // end if icnt
else {
icnt = (icnt + 0); // just for the debugger
}
HAL_READ_UINT32(AT91_PWM + AT91_PWM_ISR, pwmisr); // clears pwm-interrupt
if (pwmisr & 0xf)
icnt = (icnt + 0); // just for the debugger
} // end while pwmisr
icnt--;
HAL_RESTORE_INTERRUPTS(istate); // turns interrupts off again
cyg_interrupt_acknowledge(vector); // write eoi to AIC
pwms_ienable; // unmask pwm interrupts and leave all the rest to ecos
return CYG_ISR_HANDLED;
} // end pwm_isr
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
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] only message in thread
only message in thread, other threads:[~2012-09-13 16:20 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <5051FD4B.7070105@gmail.com>
2012-09-13 16:20 ` [ECOS] Fwd: Re: [ECOS] contents of the table " hal_interrupt_handlers" arm7 processor 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).