Looks like I'll be getting a Mega ST4 soon

[exxos]

@rubber_jonnie /AS is mostly generated from the CPU, it goes to MMU,GLUE.. if your seeing /AS going low on the CPU and not GLUE then you have a bad track.

[rubber_jonnie]

@rubber_jonnie /AS is mostly generated from the CPU, it goes to MMU,GLUE.. if your seeing /AS going low on the CPU and not GLUE then you have a bad track.

/AS at the CPU stays high all the time, with or without reset held down. Wonder if the CPU is bad, not sure I have any spare known good ones atm. I just rechecked what the book says, and it says MMU controls /AS, so I may have interpreted that as coming from the MMU, but controlling it is not the same.

On the good machine I see /AS strobe during boot, but on the bad machine, it just goes high and stays high.

My money is still on the GLUE, and probably the PCB/vias and socket, as I know that area was already reworked when I got the board, but I must be patient and check everything!

[exxos]

I'm confused because earlier you said..

Pressing reset does cause the reset pin to go low briefly though as you'd expect, and /AS briefly pulses for a few clock cycles like the good machine, but then goes high and stays high, no pulses/strobing.

Now you saying...

/AS at the CPU stays high all the time, with or without reset held down.

Which is it :)

If /AS is not pulsing low, then typical situations are the CPU does not have a clock, or RESET or HALT is held low...or CPU is bad.

[rubber_jonnie]

@exxos

Ok, let me get this straight in my head (Stupid head is so full of stuff!!) Troubleshooting this kind of stuff is way harder than I thought, but I want to learn. I went back to double check just now.

With power on, but reset not held down, the bad machine shows /AS high all the time. No strobe at all.

With power on, but reset held down, the bad machine shows /AS high all the time. No strobe at all.

With power on, the bad machine shows /AS high, buf I press and release reset, I get a very brief pulse, maybe a few clock cycles on /AS, before it goes high and stays there. So a brief strobe, indicating something happens on reset.

With power on, the bad machine shows /HALT low all the time. If I press and release reset, it goes high briefly, before it goes low again and stays there. Since it looks like it's active low, this is clearly not good. The good machine shows /HALT high unless I press and hod, or press and release reset, when it drops low, then goes high again.

On pressing and releasing reset, the reset line drops low briefly before going high again, the same as on the working machine. This looks like it is correct, at the CPU at least.

On the bad machine, the CPU has a good 8Mhz signal on CLK, regardless of reset state.

So CLK and /RESET are not the problem. /BERR stays high on both good and bad machines even through a reset cycle.

/HALT being permanently low unless briefly after reset can't be good. So what drives /HALT? It's like it starts to work and then /HALT goes low again and everything stops.

I need to put a socket back in for the CPU I think, which is where all this started!!

[exxos]

/HALT Is bidirectional, so the CPU or something else can drive it... I suspect machine is at least trying to boot, but after a couple of cycles if the CPU crashes, it will drive /HALT low itself...

If something on the bus timed out due to a address error or something, then the GLUE would set BERR low after 64 or so cycles ( I forget the exact number) ... Assuming the address is correct you should see one of the ROMx lines going low after reset.

If the address is correct based on the above, it could may well be the databus is corrupted somehow and the CPU just cannot execute instructions because the data is garbage and it locks up.

[rubber_jonnie]

@exxos Given the way I troubleshoot at work, I realised I was not working in the best way.

At work, looking at recurring problems means I would focus on a single symptom, and not 'fishing', whereas here I have been circling several symptoms at once and 'fishing' at the same time. Perhaps because I am not an electronics expert?

Maybe it's time to put in some of my work practices, by picking a single symptom and having a plan to get the data I need and assess probable causes.

So here's my train of thought:

1. I need to focus on a single symptom - /HALT is being held low by something is obvious.
2. As you say, and also stated in the 68K datasheet, /HALT can be bi-directional.
3. Thinking of point 2, I need to find out why /HALT is low. Is it the CPU? Or is it an external signal?
4. If I can work out why /HALT is low, other than going high briefly at reset, I then fix that symptom, and if the problem still persists, I move onto the next symptom.

It could be that there are multiple root causes, but if I try to look at them all at once, like I'm doing, I won't get anywhere. /HALT is the most obvious symptom so I will keep on at that. It's low, so the CPU won't run, why?

One thing at a time.

To your statement about the machine going for a couple of cycles, that seems likely. /HALT goes high on reset, then low after a few cycles, and at the same time /AS strobes until /HALT goes low again. The CPU is going straight into a/HALTed state.

Why?

/BERR never goes low during reset, or at any other time (Reset or normal running) after from what I can see. If there were a bus error, then surely I'd see it go low?

I will see if I can work out why /HALT is staying low. CPU or other component.

As ever everyone's help is appreciated.

[exxos]

/HALT is not really a cause, it is a symptom of the fault... So trying to focus on that regular pin is probably not going to help us such... You need to work out why the CPU is crashing, almost certainly it is some corruption on the address or databus ( but there can be other issues such as falsely activated interop lines due to some other fault etc)

I think removing the CPU and trying a new one in a socket is probably the first step, then do as I say and hardwire the address bus and work with the machine in a fixed state where you can monitor it all properly.

[rubber_jonnie]

@exxos I'm not saying /HALT is a cause, I'm saying it's a symptom, and I just need to investigate one symptom at a time, and I haven't been.

So yes, as you say I need to work out why the CPU is crashing, and my next step was to pull the CPU and fit a socket, and try what you've suggested.

[rubber_jonnie]

What you could try ( which should work but I haven't tried it myself) is remove the cpu and hardwire all the address lines to 0v along with AS,UDS,LDS then GLUE should decode that address and set the ROMS CE low, or at least the glue should set one of the ROMx lines low. glue should also pull DTACK low after decoding the address..

Then you can verify those 0v lines on the glue ... If you haven't got whats expected, then the address is wrong, or the glue or socket is faulty.

Right, I've ordered some replacement CPUs (@exxos You probably noticed since I got them from you :) ) I'll test them on a known good socketed system before they get to go anywhere near the Mega4, and Ill see if the CPU from the Mega4 behaves badly in the test buck.

I'll pull the CPU, fit a socket and see what the results are when I try the above, thanks for the suggestion.

[rubber_jonnie]

CPU has been removed and a socket fitted now.

ROMs have been tested in another machine and are all fine, so it isn't them.

Today I've also tested the CPU in another machine, and it's fine too. Also, with the CPU removed, I looked at what /HALT was doing on the mainboard, and it was high, suggesting that the reason /HALT is always low is that it's being driven by the CPU and not the machine.

Reading the datasheet it looks like there are two possibilities, one a double bus fault, but since /BERR stays high I don't get how it could be that, and the other is that the CPU cannot get the data off the ROMS and execute it, so sits there in a halted state because it has nothing to do.

I guess there is a 3rd option that the CPU is getting garbage and going into a halted state.

The /CE lines of the LO0 & HI0 ROMS do go low as per a working machine.

Since the diag cart doesn't show a red LED when I power on like it does with a working machine, so I am wondering if there is a GLUE decode problem as @exxos suggested, so now I have the socket fitted, I need to try his suggestion re the GLUE testing.

GLUE has been tested on another machine, so I can rule that out, as has MMU, so I am really thinking track damage or bad socket for the GLUE, what else could decode the ROM address to allow boot?