-------- 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.br...@gmail.com>
An: Michael Bergandi <mberga...@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
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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
