Synth-DIY Yahoo! Groups Archives

Thread

IRQ7 acting odd

2003-07-15 by Andrei Chichak

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

Re: [68300] IRQ7 acting odd

2003-07-15 by Scott Newell

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

Have you examined the signal with a 'scope?


>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.

Are you autovectoring?  /AVEC tied low, or using a chip select?


>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.

Hmm...can you separate the debugger from the ISR?  I'm thinking do
something in the ISR that you can see without using the debugger; toggle an
led, flip a pin, transmit out the serial port, etc.  At the very least,
increment a global variable and watch it from main line code and see if the
ISR is ever running.


newell

Re: [68300] IRQ7 acting odd

2003-07-16 by Sheldon Black

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

Show quoted textHide quoted text

----- 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\ufffd 33' 13.548" N
Lon: 113\ufffd 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

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

RE: [68300] IRQ7 acting odd

2003-07-16 by Geery, Brian

Andrei,

Did you program one of your chip selects to act as your interrupt
acknowledge?

Brian

Show quoted textHide quoted text

-----Original Message-----
From: Andrei Chichak [mailto:acpmiedm@...]
Sent: Tuesday, July 15, 2003 5:05 PM
To: 68300@yahoogroups.com
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

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

RE: [68300] IRQ7 acting odd

2003-07-16 by Melear Charles-rdph40

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

Show quoted textHide quoted text

-----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]

RE: [68300] IRQ7 acting odd

2003-07-16 by Melear Charles-rdph40

Andret,
 
The CPU32 is very good about giving stack information.  When the machine takes a double bus fault, there will be a lot of information put on the stack.  If you will get that data and send it to me, I will try to help you decipher it.  
 
The most likely cause for a double bus fault is that there is nothing to "DSACK" the level 7 interrupt service routine.  However, the information put on the stack will help determine what is going on.
 
What you might have to do is write a short routine to dump the information on the stack.  If the machine simply halts, you can take the debugger and manually enable the stack memory and then read the stack memory through the debugger.
 
If none of this makes sense, send me an email and I will give more details.
 
Charlie

Show quoted textHide quoted text

-----Original Message-----
From: Andrei Chichak [mailto:acpmiedm@...]
Sent: Tuesday, July 15, 2003 6:05 PM
To: 68300@yahoogroups.com
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

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=214399794> 	

---------------------------------------------------
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]

RE: [68300] IRQ7 acting odd

2003-07-16 by Andrei Chichak

Good morning Scott, Sheldon, Brian, Charlie, and everybody else,

I think that I am missing something here, and I think it has a lot to do 
with AVEC and DSACK.

What I am trying to do is have the external RTC clock yank down on IRQ7* 
and trigger the execution of some code on the '332. The RTC looks like 128K 
of static RAM and is mapped onto locations 0x600000 to 0x61FFFF controlled 
by CS5, thus;

         MOVE.W  #$6005,$FFFA60  ; CSRBR5 128k area reserved at $600000 for 
NVRAM and clock
         MOVE.W  #$5830,$FFFA62  ; CSOR5

I will not be providing an autovector vector on the data bus, just relying 
on IRQ7* vectoring through location VBR+0x7c. So I do not turn on the AVEC 
bit in CSOR5 or any other CSOR register.

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.

Is the processor expecting the vector to be supplied on the data bus at 
interrupt time? Can't I just use the exception vector table with a simple, 
low going, input pulse? Does DSACK have to be externally generated? And 
what about Naomi? (sorry I just had to throw that in).

Thanks,
Andrei

At 07:15 AM 7/16/2003 -0700, you wrote:
>Andret,
>
>The CPU32 is very good about giving stack information.  When the machine 
>takes a double bus fault, there will be a lot of information put on the 
>stack.  If you will get that data and send it to me, I will try to help 
>you decipher it.
>
>The most likely cause for a double bus fault is that there is nothing to 
>"DSACK" the level 7 interrupt service routine.  However, the information 
>put on the stack will help determine what is going on.
>
>What you might have to do is write a short routine to dump the information 
>on the stack.  If the machine simply halts, you can take the debugger and 
>manually enable the stack memory and then read the stack memory through 
>the debugger.
>
>If none of this makes sense, send me an email and I will give more details.
>
>Charlie

-------
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

RE: [68300] IRQ7 acting odd

2003-07-16 by Scott Newell

>I think that I am missing something here, and I think it has a lot to do 
>with AVEC and DSACK.

I think so too...either tie the /AVEC pin low or use a chip select to
generate the /AVEC signal internally.


>I will not be providing an autovector vector on the data bus, just relying 

As I understand it, the term autovector means that the you're not using the
data bus for the interrupt ack.  I think you've got the terminology
backwards here.


>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.

This part sounds good.


>Is the processor expecting the vector to be supplied on the data bus at 
>interrupt time? Can't I just use the exception vector table with a simple, 

With your current config, I believe that it is.  Should be an easy fix if
you have an unused chip select generator.  Section 4.8.3 in the user's
manual is the relevant bit.


newell

RE: [68300] IRQ7 acting odd

2003-07-16 by Geery, Brian

Andrei,

You're not the only one to get confused on this, but you do need to program
one of your chip selects to interrupt acknowledge.  I like using Chip Select
6 because I typically have that pin defined as A19.  Even though the pin is
defined as A19, I can still use the CS6 logic to provide the interrupt
acknowledge.  There is a section in the user's manual titled "Using
Chip-Select Signals for Interrupt Acknowledge" that tells you exactly how to
do it.  For a reference, I wrote $FFF8 to CSBAR6 & $6B81 to CSOR6.

Brian

Show quoted textHide quoted text

-----Original Message-----
From: Andrei Chichak [mailto:acpmiedm@telusplanet.net]
Sent: Wednesday, July 16, 2003 9:50 AM
To: 68300@yahoogroups.com
Subject: RE: [68300] IRQ7 acting odd

Good morning Scott, Sheldon, Brian, Charlie, and everybody else,

I think that I am missing something here, and I think it has a lot to do 
with AVEC and DSACK.

What I am trying to do is have the external RTC clock yank down on IRQ7* 
and trigger the execution of some code on the '332. The RTC looks like 128K 
of static RAM and is mapped onto locations 0x600000 to 0x61FFFF controlled 
by CS5, thus;

         MOVE.W  #$6005,$FFFA60  ; CSRBR5 128k area reserved at $600000 for 
NVRAM and clock
         MOVE.W  #$5830,$FFFA62  ; CSOR5

I will not be providing an autovector vector on the data bus, just relying 
on IRQ7* vectoring through location VBR+0x7c. So I do not turn on the AVEC 
bit in CSOR5 or any other CSOR register.

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.

Is the processor expecting the vector to be supplied on the data bus at 
interrupt time? Can't I just use the exception vector table with a simple, 
low going, input pulse? Does DSACK have to be externally generated? And 
what about Naomi? (sorry I just had to throw that in).

Thanks,
Andrei

At 07:15 AM 7/16/2003 -0700, you wrote:
>Andret,
>
>The CPU32 is very good about giving stack information.  When the machine 
>takes a double bus fault, there will be a lot of information put on the 
>stack.  If you will get that data and send it to me, I will try to help 
>you decipher it.
>
>The most likely cause for a double bus fault is that there is nothing to 
>"DSACK" the level 7 interrupt service routine.  However, the information 
>put on the stack will help determine what is going on.
>
>What you might have to do is write a short routine to dump the information 
>on the stack.  If the machine simply halts, you can take the debugger and 
>manually enable the stack memory and then read the stack memory through 
>the debugger.
>
>If none of this makes sense, send me an email and I will give more details.
>
>Charlie

-------
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

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

RE: [68300] IRQ7 acting odd

2003-07-16 by Andrei Chichak

Brian and Scott,

Would this prevent the interrupt from firing in the first place?

(I'm not avoiding trying out the extra chip select setup, I'm just waiting 
to get time on the hardware).

Andrei

RE: [68300] IRQ7 acting odd

2003-07-16 by Scott Newell

>Would this prevent the interrupt from firing in the first place?

I've never used anything other than autovector interrupts, so I'm not
really sure.  I would have guessed (and this is just a guess) that it would
have either hung waiting for the external vector to be presented, or that
it would have used floating data bus lines as a vector, maybe ending in
some kind of bus fault.  Without an interrupt ack, I would not have guessed
that you'd be able to run at all after /IRQ7 went low.


>(I'm not avoiding trying out the extra chip select setup, I'm just waiting 
>to get time on the hardware).

I'm just waiting for Mr. Melear to weigh in on this one again... ;-)


newell

RE: [68300] IRQ7 acting odd

2003-07-16 by Andrei Chichak

Okay, the programming of CS6 (as it happens, this was the next open CS) to 
the values that Brian Geery gave ("$FFF8 to CSBAR6 & $6B81 to CSOR6") 
actually worked. I am now getting my interrupt.

I suspect that there is a lot more information in the CSBAR fields that I 
will have to understand deeply. Right now this seems to be JPBM (just plain 
black magic).

Charlie, can you explain why this worked and how to properly configure a 
chip select for AVEC/DSACK generation?

Thanks again,
Andrei

RE: [68300] IRQ7 acting odd

2003-07-16 by Melear Charles-rdph40

Hello everyone,
 
When an interrupt occurs, the following happens:
 
1.  some stuff is put on the stack
2.  the interrupt acknowledgement cycle occurs
3. either AVEC or DSACK is used to terminate the IACK cycle
4.  the Interrupt Service Routine is entered.
 
If nothing terminates the IACK cycle, the machine will just hang there and no further bus activity or instruction fetches occur.
 
If the IACK cycle is terminated with BERR (either external or from the internal Bus Error Monitor) a spurious interrupt exception will be taken.
 
 
 
Here is a question for the person having the problem.  What happens when IRQ7 occurs?  Does program execution continue, does program execution appear to stop, or what?
 
If program execution appears to stop, the problem is almost certainly that there is no AVEC or DSACK for the Interrupt Acknowledgement Cycle.
 
You can get an internall AVEC or DSACK by programming the chip select logic.  Program the Base Address Register to $FFF8, and program the Option Register for ASYNC, BOTH BYTES,  READ and WRITE, AS, zero wait states, CPU space, IPL field = %000 for all interrupts or put in the interrupt level you want to respond to, AVEC = 1 for autovector, AVEC = 0 for DSACK.
 
REgards,
 
Charlie

Show quoted textHide quoted text

-----Original Message-----
From: Scott Newell [mailto:newell@...]
Sent: Wednesday, July 16, 2003 12:51 PM
To: 68300@yahoogroups.com
Subject: RE: [68300] IRQ7 acting odd

>Would this prevent the interrupt from firing in the first place?

I've never used anything other than autovector interrupts, so I'm not
really sure.  I would have guessed (and this is just a guess) that it would
have either hung waiting for the external vector to be presented, or that
it would have used floating data bus lines as a vector, maybe ending in
some kind of bus fault.  Without an interrupt ack, I would not have guessed
that you'd be able to run at all after /IRQ7 went low.

>(I'm not avoiding trying out the extra chip select setup, I'm just waiting 
>to get time on the hardware).

I'm just waiting for Mr. Melear to weigh in on this one again... ;-)

newell

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=977943934> 	

---------------------------------------------------
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]

RE: [68300] IRQ7 acting odd

2003-07-16 by Melear Charles-rdph40

Hello everyone,
 
Interrupt Acknowledgement Cycles always drive the address bus to $FF FFFx.  Programming the Base Address register to $FFF8 will give the address match.
 
The programming of the option register to $6B01 will make the SPACE field = 00 for CPU space, the IPL field = 000 for all interrupts, and AVEC = 1 for generate AVEC.
 
Regards,
 
Charlie

Show quoted textHide quoted text

-----Original Message-----
From: Andrei Chichak [mailto:acpmiedm@...]
Sent: Wednesday, July 16, 2003 1:17 PM
To: 68300@yahoogroups.com
Subject: RE: [68300] IRQ7 acting odd

Okay, the programming of CS6 (as it happens, this was the next open CS) to 
the values that Brian Geery gave ("$FFF8 to CSBAR6 & $6B81 to CSOR6") 
actually worked. I am now getting my interrupt.

I suspect that there is a lot more information in the CSBAR fields that I 
will have to understand deeply. Right now this seems to be JPBM (just plain 
black magic).

Charlie, can you explain why this worked and how to properly configure a 
chip select for AVEC/DSACK generation?

Thanks again,
Andrei

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=861798698> 	

---------------------------------------------------
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]

RE: [68300] IRQ7 acting odd

2003-07-16 by Melear Charles-rdph40

If you don't generate an AVEC signal from some source, the &*%$$^&&$#^&@ thing ain't going to work.

Charlie

Show quoted textHide quoted text

-----Original Message-----
From: Andrei Chichak [mailto:acpmiedm@...]
Sent: Wednesday, July 16, 2003 10:50 AM
To: 68300@yahoogroups.com
Subject: RE: [68300] IRQ7 acting odd

Good morning Scott, Sheldon, Brian, Charlie, and everybody else,

I think that I am missing something here, and I think it has a lot to do 
with AVEC and DSACK.

What I am trying to do is have the external RTC clock yank down on IRQ7* 
and trigger the execution of some code on the '332. The RTC looks like 128K 
of static RAM and is mapped onto locations 0x600000 to 0x61FFFF controlled 
by CS5, thus;

         MOVE.W  #$6005,$FFFA60  ; CSRBR5 128k area reserved at $600000 for 
NVRAM and clock
         MOVE.W  #$5830,$FFFA62  ; CSOR5

I will not be providing an autovector vector on the data bus, just relying 
on IRQ7* vectoring through location VBR+0x7c. So I do not turn on the AVEC 
bit in CSOR5 or any other CSOR register.

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.

Is the processor expecting the vector to be supplied on the data bus at 
interrupt time? Can't I just use the exception vector table with a simple, 
low going, input pulse? Does DSACK have to be externally generated? And 
what about Naomi? (sorry I just had to throw that in).

Thanks,
Andrei

At 07:15 AM 7/16/2003 -0700, you wrote:
>Andret,
>
>The CPU32 is very good about giving stack information.  When the machine 
>takes a double bus fault, there will be a lot of information put on the 
>stack.  If you will get that data and send it to me, I will try to help 
>you decipher it.
>
>The most likely cause for a double bus fault is that there is nothing to 
>"DSACK" the level 7 interrupt service routine.  However, the information 
>put on the stack will help determine what is going on.
>
>What you might have to do is write a short routine to dump the information 
>on the stack.  If the machine simply halts, you can take the debugger and 
>manually enable the stack memory and then read the stack memory through 
>the debugger.
>
>If none of this makes sense, send me an email and I will give more details.
>
>Charlie

-------
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

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

RE: [68300] IRQ7 acting odd

2003-07-16 by Andrei Chichak

Everyone, thank you very much for your help. it works great.

Andrei

At 11:28 AM 7/16/2003 -0700, you wrote:
>Hello everyone,
>
>Interrupt Acknowledgement Cycles always drive the address bus to $FF 
>FFFx.  Programming the Base Address register to $FFF8 will give the 
>address match.
>
>The programming of the option register to $6B01 will make the SPACE field 
>= 00 for CPU space, the IPL field = 000 for all interrupts, and AVEC = 1 
>for generate AVEC.
>
>Regards,
>
>Charlie

-------
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

RE: [68300] IRQ7 acting odd

2003-07-16 by Dimiter Popoff

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

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:

Show quoted textHide quoted text

>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