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] |
Bob,Hi Mike,
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
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!
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] |