Yahoo Groups archive

68300

Index last updated: 2026-04-29 00:01 UTC

Message

RE: [68300] IRQ7 acting odd

2003-07-16 by Andrei Chichak

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.