z80 crashes after executing some instructions

Question

I'm building my own Z80 computer but I'm having a very strange problem. Consider this code:

ld a,0xaa
out (00),a
jp a

That works as expected, outputting 0xaa on port 0x00. Now consider this code:

 ld a,0xaa
hello:
 out (00),a
 inc a
 jp hello

This outputs exactly 87 times to port 0x00, then it crashes. I took a look at the buses to see what's happening and it seems that it accesses incrementally addresses on memory when it's not needed. I read a year ago that this was a thing due to Z80's architecture, but the problem happens when this incremental access reaches 10000000(bin). This is what I see in the logic analyser:

The increment is happening on address 3 4 5 6 7 and 8, and when the 8th modulates, iorq stops and the CPU does weird stuff. Can any one please help?

---

EDIT:

I found the answer but if you have the same or similar issue, you should definitely read Spektre's and tofro's answers because they list a lot of very possible problems that could cause this.

Answer 1

You might be having some sort of short between A7 and some other CPU line. Your program doesn't use/need this line, but refresh does. The fact that "weird behavior" starts when A7 is toggled for the first time, definitely hints that it is connected to something it shouldn't be.

Depending on where it is connected to, if your memory fetch (from ROM) is not properly synchronized (don't read from the bus when /RFSH is low) with the /RFSH signal, you might then pick up (during the instruction fetch) stray bytes from areas where no ROM is present and thus the wrong instructions.

Answer 2

There is a lot what could go wrong here a list of hints:

1. code

   I see no ORG directive in the code so are you sure you are placing your code in the right place of memory? Also I would feel safer with interrupts disabled. I would expect something like:

       org 0
   reset:
       di
       ld a,0xAA
   loop0:
       out (00),a
       inc a
       jp loop0
   

2. Interrupts

   There are /NMI and /INT pins causing interrupt (and /RESET is also form of interrupt too). Hope they are properly electrically handled (with pull up resistor). In case you want to use also Interrupts you need to add proper interrupt handlers for your code but those require stack so you also need RAM to work properly unless they are used as Watch dog for periodic reset only.

   Beware di disables only the /INT pin so /NMI and /RESET will still interfere with your code if Low.

   There is also the /WAIT and /BUSRQ pins that can effectively stop the CPU if un-handled.

   So to be more safe I would change the code a bit more:

       org 0
   reset:
       di
       ld a,0xAA
   loop0:
       out (00),a
       inc a
       jp loop0
   
       org 0x66
   NMI:
       jp reset
   

   Note that I did not use retn because you do not have any stack.

3. Analyzer signal

   As the other comments mentioned you are probing the buses of the Z80 so you are catching everything instead of IO access only. That means you got address bus swapping between pc (program counter) and r (refresh) registers and IO address +/- some undefined behavior.

   The data bus is swapping between each OP code of your assembly code the IO data and also +/- some undefined behavior.

   So the IO access is only a small fraction of what you see. To identify it you should investigate /IORQ,/RD,/WR signals.

   The Z80 IO address space is officially only 8bit so probing 8th bit of address has not much sense. To move to 16 bit IO address space use the

   out (c),a
   

   which uses bc.

4. What does it mean Z80 crashes exactly?

   I am not aware of any Crash ability of Z80. More likely it executes HALT or something waiting for HW response that never comes ... Are you sure your logic analyzer probing does not interfere with the buses? Is the CPU clock still running? Is M1 pin toggling?

5. High frequency and circuit

   There is also possibility that you got electrical and or timing problems. What clock are you using for CPU? Is your ROM fast enough? Do you got proper shielding of your buses and are they short enough? Do you got proper blocking ground and caps nearby to lower the impulse load on the power supply?

   If not lower your clock to more reasonable values. Also I strongly recommend to read this:

   • Thought I found serial port - broke embedded device instead! Help?

   Also remember any un-handled input pin of IC is an antenna and if high frequency square pulses are nearby you can expect weird things to happen at anytime ...

   And finally if counting to a specific value stops the CPU it might hint you got short circuit of some higher address or data bus line with /INT,/NMI ,/BUSRQ or /RESET check for that some short circuits on PCB are invisible to naked eye usually scrapping the gaps between copper paths with a needle helps ...

Answer 3

Found the actual problem (i believe).

I was used to connecting rom's /CS to A15 to have both a rom and a ram later on, on a 6502 system but as it turns out there is a handy /MREQ signal on the Z80.Excluding all the address decoding, the solution was to connect /MREQ to /CS of the rom.