Z80 interrupt, er, always interrupting?

[Tim Williams]

I'm moving on to interrupt driven timing, so I set up a simple shift,
display and delay interrupt handler on my Z80 deal. I have a pullup
resistor on /INT and a jumper momentary to ground (unfortunately, I
don't have any pushbuttons with me, nor anything reasonable to
debounce it) to trigger.

The problem is, once I power up and reset the circuit and it enters
its infinite do-nothing loop (that much is working okay), I hit
interrupt and it works, yes, but then it keeps on working. It's not
returning. What's more, I can interrupt the handler in the middle of
its delay, right in the middle between a DI and an EI. That should be
impossible!

I'm not mistakenly using the NMI; I have RETN at 66h, and the /NMI pin
does nothing (as well it should). (I'm running IM 1 and the handler
is at 38h, and if it weren't getting there, it wouldn't respond very
well at all, so I know that is correct.) INT is supposed to be level
triggered, only when interrupts are enabled, and either interrupts are
disabled after an INT (I'm not clear on that) or I disable them
immediately (I have DI just in case). Even if it is firing multiple
interrupts (IFF1 remains set after INT response?), it should still pop
them off, one by one, as each completes, eventually stopping. But it
doesn't!

Tim

 

[Tim Williams]

On closer inspection, I *did* have the NMI pin... now that wouldn't
have done anything ordinarily, but I also managed to leave /INT
floating... :-o

Tim

 

[Michael]

I'm moving on to interrupt driven timing, so I set up a simple shift,
display and delay interrupt handler on my Z80 deal. I have a pullup
resistor on /INT and a jumper momentary to ground (unfortunately, I
don't have any pushbuttons with me, nor anything reasonable to
debounce it) to trigger.

The problem is, once I power up and reset the circuit and it enters
its infinite do-nothing loop (that much is working okay), I hit
interrupt and it works, yes, but then it keeps on working. It's not
returning. What's more, I can interrupt the handler in the middle of
its delay, right in the middle between a DI and an EI. That should be
impossible!

I'm not mistakenly using the NMI; I have RETN at 66h, and the /NMI pin
does nothing (as well it should). (I'm running IM 1 and the handler
is at 38h, and if it weren't getting there, it wouldn't respond very
well at all, so I know that is correct.) INT is supposed to be level
triggered, only when interrupts are enabled, and either interrupts are
disabled after an INT (I'm not clear on that) or I disable them
immediately (I have DI just in case). Even if it is firing multiple
interrupts (IFF1 remains set after INT response?), it should still pop
them off, one by one, as each completes, eventually stopping. But it
doesn't!

Tim

Your post sent my brain toddling off to find its 1990's archives. It's been a while since I coded
for that beastie. I have a mental image of the breadboard I used for Z80, and ISTR a radial cap. on
!Int. along with a pullup. Hmmm... probably not. I must be thinking of the reset pin. (Not even
sure, at this point, if Z80 *has* a reset pin!)

I'm glad you worked out the problem on your own. I sure couldn't make any worthwhile suggestions
without digging out some old notebooks.

Isn't it fascinating how micros (for one example) constantly show us that what absolutely cannot be,
absolutely can be... and is? Last week I was swearing at my outdated MPLAB (Microchip) software
because it blithely skipped along, acting on the external 32KHz "stimulus" being fed to Timer1,
while the supposedly identical breadboarded 16F877A just sat there quiet and dumb. Obviously there
was something wrong but the stupid software didn't know. Well, not so fast! My code and the
simulator were fine. The problem was with the real hardware: this human had wired 32KHz to the
wrong pin of the micro. I was torn between feeling good that my design was correct and worked and
feeling stupid for ranting at MPLAB.

 

[Tim Williams]

Your post sent my brain toddling off to find its 1990's archives.  It'sbeen a while since I coded
for that beastie.  I have a mental image of the breadboard I used for Z80, and ISTR a radial cap. on
!Int. along with a pullup.  Hmmm... probably not.  I must be thinkingof the reset pin. (Not even
sure, at this point, if Z80 *has* a reset pin!)

Ya, that'd be reset. The manual shows an RC on the reset, although
what I have apparently isn't long enough (4.7k + 47nF). Funny how it
just sits there idle until I (manually) reset it; I suppose this is
because the quartz clock oscillator takes miliseconds to stabilize, in
which time the dynamic NMOS has already forgotten where it was?

Isn't it fascinating how micros (for one example) constantly show us thatwhat absolutely cannot be,
absolutely can be... and is?  Last week I was swearing at my outdated MPLAB (Microchip) software
because it blithely skipped along, acting on the external 32KHz "stimulus" being fed to Timer1,
while the supposedly identical breadboarded 16F877A just sat there quiet and dumb.   Obviously there
was something wrong but the stupid software didn't know.  Well, not so fast!   My code and the
simulator were fine.  The problem was with the real hardware: this human had wired 32KHz to the
wrong pin of the micro.  I was torn between feeling good that my designwas correct and worked and
feeling stupid for ranting at MPLAB.

Ahh, sure. The other day I had an ATmega32 in lab which had no reason
at all not to work. The code reads correctly, and even seems to work,
but only once, not repeatedly (kind of the inverse of what's above, I
guess!). Turns out I had forgotten to read PINxx instead of PORTxx to
get user input.

Most of the time I try to take a Zen? attitude about these things..
I'm quite good, for the most part, at reading code (at least when I
take the time to read it ). So I can rule out obvious things, and
I can work through the code and see what it's doing and if it's doing
it right. That leaves the subtle things (like PORT vs. PIN). I know
well enough that, if it's not obvious on first look, it may not be
obvious on subsequent looks, so I might go do something else, or I
might analyze it in more detail, scraping it down to what should be
the bare essentials. But sometimes I forget the "Zen" part and do
something as rash as post about it, which inevitably leads to a
redoubled effort to find the actual problem, if not find it in the
process of writing that post!

Tim