68300

Hello everyone,
 
Now before I start, let me tell you that all I know about C is that it means "yes" in Spanish.
 
Something that you need to know about interrupts is this:
 
IRQ 6 thru 1 are level sensitive.  If you tie one of these interrupts to ground, then as soon as the the I-bits are lowered to a value less than the number of the IRQ line just tied to ground, an interrupt will occur.  The level of the interrupt will be written to the I-bits in the CPU status register perventing further interrupts at that level.  As soon as the Interrupt Service Routine is exited with an RTE instruction, the original value of the I-bits will be restored and the external interrupt line will be immediately recognized.
 
Moral of storey:  If you tie an interrupt line to ground on a CPU32 based product, you will continuously cycle in the interrupt's service handler.
 
 
 
Next verse:  Level 7 interrupts are BOTH LEVEL AND EDGE SENSITIVE.  Yes, that's right everyone.  Been there, done that.  Here is how level 7 works.  When a negative edge occurs on the external level 7 IRQ line, an interrupt will be signaled.  Then the ISR is entered.  Now here is the magic.  If the IRQ7 line goes high and subsequently takes another negative transition (even while inside the Interrupt Service Handler) a new interrupt will be signaled.
 
Here is the little known part.  If IRQ7 takes a negative transition AND the interrupt service handler is entered AND the IRQ7 pin remains low when the level 7 ISR is exited with an RTE instruction, (now read this carefully) a new level 7 interrupt will be signaled.  That's right, if IRQ7 goes low and remains low and continues to be low when the interrupt service routine is exited, a new level 7 interrupt will be signaled even though there was never a transition on the external level 7 interrupt pin.
 
Moral of storey # 1  --  Level 7 interrupts have both a level sensitive and an edge sensitive component.
 
Moral of storey # 2  -  Level 7 interrupts (as well as all the other interrupts) must be de-asserted inside of the appropriate interrupt service handler.
 
Moral of storey # 3  -  The level 7 interrupt recognition circuitry is reset when the IRQ7 pin takes a zero to one transition OR the when there is a write to the CPU Status Register.  Recall that an RTE restores the "stacked value" of the CPU Status Register and this counts as a "write operation".
 
 
I hope all this is clear and addresses the question that the original writer was asking.
 
Regards,
 
Charlie
 
 
 
 
 
 
 
 
 

-----Original Message-----
From: Sheldon Black [mailto:sblack2@...]
Sent: Wednesday, July 16, 2003 1:13 AM
To: 68300@yahoogroups.com
Subject: Re: [68300] IRQ7 acting odd


Hello Andrei,

It has been a couple of years since my SDS 68332 work, but I had a line in
my SDS config file that looked like:

set vectskip=28,64,66


The file, c:\sds70\init\sstep.ini contained a line that was:
alias _config 'source \sheldon\isa_x1\68332.cfg'

The \sheldon\isa_x1\68332.cfg file contained the vectskip command.

After download to ram, SDS will overwrite all of the vectors except for the
ones that you tell it to skip.

Memory here is fuzzy, but I think the IRQ lines are level sensitive, so if
you pull it low and the SDS routine isn't really servicing it to pull it
high, it will keep ISR'ing to their dummy vector. This cycle in and out of
the ISR may be related to your double bus fault issue.

If this works, please let me know. If I'm cracked, just ignore me.

Sheldon Black


----- Original Message -----
From: "Andrei Chichak" <acpmiedm@...>
To: <68300@yahoogroups.com>
Sent: Tuesday, July 15, 2003 4:05 PM
Subject: [68300] IRQ7 acting odd


Hi all,

I have a Benchmarq bq4842y battery backed ram RTC chip with INT* tied to
IRQ7* directly (no pullup).

I have programmed PFPAR with a value of 0x80. DDRF is irrelevant but has a
value of 0x13.

VBR is 0x100000. Location 0x10007C has 0x10E0C8 (address of the interrupt
routine). Interrupt routine is declared as such and ends in RTE.

I have placed a breakpoint at the beginning of the interrupt routine (using
SDS debugger) and the breakpoint never fires. When the RTC interrupt
happens I can watch the INT* line go low and from that point on, when I try
to halt the processor, SDS complains that it had to use a double bus fault
to halt the processor. Prior to the interrupt the processor will halt
properly.

If PFPAR is set to 0x00, I can always halt the processor properly even
after the INT* line is asserted by the clock chip.

Any ideas?

Andrei

-------
Andrei Chichak               #200 10835-120 Street
Senior Software Developer    Edmonton, Alberta
Pulmonox Medical Inc.        Canada
                              T5H 3P9
                              (W) (780) 451-3660
                              (F) (780) 452-0169

Lat: 53° 33' 13.548" N
Lon: 113° 31' 43.164" W



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> 




Yahoo! Groups Sponsor	

ADVERTISEMENT
 <http://rd.yahoo.com/M=194081.3551198.4824677.1261774/D=egroupweb/S=1706554205:HM/A=1663535/R=0/SIG=11ps6rfef/*http://www.ediets.com/start.cfm?code=30504&media=atkins> click here	
  <http://us.adserver.yahoo.com/l?M=194081.3551198.4824677.1261774/D=egroupmail/S=:HM/A=1663535/rand=567132343> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]