1. Home
  2. Electronics Design
  3. Z80 interrupt, er, always interrupting?

Z80 interrupt, er, always interrupting?

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

Reply to
Tim Williams
Loading thread data ...

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

Reply to
Tim Williams

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.

--
Michael
Reply to
Michael

been a while since I coded

80, and ISTR a radial cap. on

of the reset pin. (Not even

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?

what absolutely cannot be,

PLAB (Microchip) software

" being fed to Timer1,

and dumb. =A0 Obviously there

fast! =A0 My code and the

n had wired 32KHz to the

was correct and worked and

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

Reply to
Tim Williams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.