This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: Re: contents of the table " hal_interrupt_handlers" arm7 processor


-------- 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: pwm_isr.c
Description: Text document

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]