[ECOS] Fwd: Re: [ECOS] contents of the table " hal_interrupt_handlers" arm7 processor

[Bob Brusa]

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





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



-------------- next part --------------
-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss