Dimiter, You bring up a VERY good point, if the RTC asserts its interrupt line while the system is off (which it can do), when the system boots the boot code configures PORTF to handle interrupts, and the code will immediately fire. The system will probably not be ready for the results of the interrupt. I will have to delay the configuration of PORTF until after the system is completely up. The choice of IRQ7 was made by the resident EE, you can imagine how little say anybody else gets :-) Andrei At 12:19 AM 7/17/2003 +0300, you wrote: >Andrei, > > >Within the interrupt routine, I clear the source of the interrupt returning > >IRQ7* to the high state then do the RTE. This should avoid the level > >sensitivity reasserting the interrupt. > >the only chance you might have to clear the non-maskable IRQ is to do so >by the very first instruction in the NMI handler. Most likely you won't >have even this chance because the write to the peripheral which generated >the NMI will be during the last cycle of the instruction, and until >the peripheral deasserts the NMI, it will probably be recognised by the CPU. > >Anyway, this is not the main point. > > Using IRQ 7 for anything less than what would make you consider using >reset is a very bad idea; it is not meant for such use. > There is no way you can guarantee your system will be in a recoverable >state when you assert IRQ 7. > If you really need that interrupt to be with the highest priority, >you may consider using IRQ 6 - and for any other sources use IRQ 5 and below. > >Dimiter
Message
RE: [68300] IRQ7 acting odd
2003-07-16 by Andrei Chichak
Attachments
- No local attachments were found for this message.