SE/30 FPU trouble

[mmjs]

Hey everyone,
This is a follow up to this thread which seemed to end in success, but after a couple of weeks using my newly rebuilt SE/30 Bolle board, I started to experience strange issues that resulted in non-functional FPU.

For context, my board is fully socketed and uses a Rominator II.

I first noticed intermittent SCSI problems. I'm noting because this may, or may not be related. They've occurred a few times, but for the most part SCSI is working fine.

Around the same time I also noticed intermittent crashes when downloading files via FTP. I went ahead and ran a Snooper test, which showed CPU and FPU failures, and reported obviously incorrect CPU frequency:



This was strange, but at this point I still didn't suspect the FPU. After a couple of reboots, the FPU would no longer work, and I actually stopped being able to boot into the system (System 7.1.1) at all. When I took out the FPU, I would get a stable system, but many applications would fail with "error of type 90" (i.e. "an FPU instruction was executed but the machine doesn't have an FPU") which makes sense.



I had another FPU that I thought was fine, and with this FPU the machine would boot successfully, but all applications requiring an FPU would fail with "error of type 1". Now this suggests that with this FPU the computer is aware that it has it, but it still fails to use it. At this point I suspected this unit as well, so I ordered a replacement.

Well, this replacement arrived today, and it fails in the exactly the same way with an "error of type 1" when an application needing an FPU is started.

I've verified all the connections between the FPU, the bus and GLUE, and they all check out. The one odd thing I did notice is that if I scope out the CS line, which is controlled by the GLUE chip, it stays high from the moment power is turned on, including when FPU-needing applications are started. There are however no indications that there's a short to 5V or another constantly high line that would explain this.

Any suggestions are very welcome!

 

[obsolete]

I hate to say this, but is it possible that the problem is actually in the glue chip?

 

[Melkhior]

I scope out the CS line, which is controlled by the GLUE chip, it stays high from the moment power is turned on, including when FPU-needing applications are started

Maybe some inputs to the GLU are damaged. Normally, to generate /FPU_CS, it needs all three FC lines and A[13..20]. If one or more of those is 'stuck' or unreliable, /FPU_CS would be affected. The address lines would probably cause additional issues, but I don't think FC is sued for anything other than detecting a coprocessor cycle. So I suggest making sure the FC lines have no issue between the CPU and GLU. You could also scope them during FPU accesses, they should be all-ones during coprocessor cycles (and at least one of them zero at all other times).

 

[mmjs]

Thank you both @obsolete and @Melkhior !

In the end this was definitely caused by bad contacts in sockets. Thanks for pointing towards the GLU -- eventually, I found socket issues with SCSI, GLU and FPU. I directly soldered SCSI and GLU, and got a new socket for the FPU.

I would have directly soldered the FPU as well, but its pads are so tight and there are so many plastic components already installed around it I wasn't sure if I was gonna make it without damaging things around it.

Definitely a lesson learned about the dangers of sockets and the repeated removal of chips in them.

 

[obsolete]

Awesome! Glad to hear you got it figured out.