Fried SE/30 Ethernet Card?

[Reasons.]

Thank you both! These are super helpful--I've ordered a few oscilators and hopefully I can get this up and going sometime this week or next.

 

[Reasons.]

Here's a screenshot of the Asante troubleshooting tool, by the way, in case it's helpful:

 

[Mk.558]

You may want to hit up Glenn Anderson on TinkerDifferent as he just might be a subject matter expert on this matter. I'd wait till the oscillators (technically there's another one on the 10BASE-T daughtercards) are replaced though, but if the cable is installed correctly, you have not doubled-up on FPUs, oscillators replaced -- that'd be something he'd know more than I would about.

 

[zigzagjoe]

That is a weird one. For me, I believe the loopback test was the one that was failing, IIRC with TX reported as failed. Your error reads like one of the card's SRAMs is having issues, though the expect/actual don't mismatch as would be implied (for a failure). The crystals are only used for xmit/receive, so this error (if accurate & consistent) points at a logic issue.

You may want to run the tests a few times and see if it repeatably has the same error.

 

[Mk.558]

As far as I can tell that 20MHz onboard clock is also used for the IC U1 operations. The datasheet specifically mentions an external reference clock signal a few times. I'd imagine if the crystal was gone haywire the IC wouldn't be able to operate normally. However I'll also admit when mine was acting up, the tests all passed except the ones involving "actually networking" -- loopback tests failed, EtherTalk wouldn't work, FTP wouldn't work etc.

 

[zigzagjoe]

As far as I can tell that 20MHz onboard clock is also used for the IC U1 operations. The datasheet specifically mentions an external reference clock signal a few times. I'd imagine if the crystal was gone haywire the IC wouldn't be able to operate normally. However I'll also admit when mine was acting up, the tests all passed except the ones involving "actually networking" -- loopback tests failed, EtherTalk wouldn't work, FTP wouldn't work etc.

It's only used for the ENDEC section per the block diagram. A bus clock derived from the system clock is used to clock bytes into the buffer SRAM/perform other functions. Unfortunately it is that buffer SRAM is being called out as bad in that screenshot (if accurate), which in reality could be a number of issues - GALs, bus buffers, or the SRAM.

 

[Reasons.]

Really appreciate the insight here--I'll definitely start with the clock crystal since it's cheap, but after that I'll probably head over to Tinker Different and ask there. The RAM error is repeatable and shows up every time I run the test, but there's never any actual disagreement between the expected and reported result. Can confirm there's not a second FPU installed and the cable is oriented correctly (though I'll check post-replacement to verify).

I'll probably do the oscillator on the daughterboard while I'm in there--should I be good to use the same spec as the one on the mainboard?

 

[Mk.558]

Mine has the same text on both, so probably yeah. The daughter card won't kick errors like that though, I reckon.

Glenn over there will probably already have a reverse engineered schematic ready to go. Man is ready to play ball with older ethernet cards like this -- if you look at his post history, he's been taking older cards that don't have 10BASE-T jacks and upgrading them.

 

[zigzagjoe]

Mine has the same text on both, so probably yeah. The daughter card won't kick errors like that though, I reckon.

Glenn over there will probably already have a reverse engineered schematic ready to go. Man is ready to play ball with older ethernet cards like this -- if you look at his post history, he's been taking older cards that don't have 10BASE-T jacks and upgrading them.

Bolle already reversed the schematic. Note that the ROM is using a PAL symbol but pin #s are correct.

 

[Reasons.]

Just received the oscillators and swapped the one on the main board. After testing continuity and making sure it works as expected I'm still getting the same three errors:

• RAM test failed at f99d0000H, expect: 0H, actual 0H
• NIC Arbitration Failed
• Loopback 3 test Failed

I'll try to swap the one on the daughterboard, but my gut says this is another issue. Time to finally make a Tinker Different account, I guess.

 

[zigzagjoe]

That more or less confirms that you have some kind of logic issue.

Looking through the GAL logic, $f99d0000 should be the first address in the onboard RAM. A31-A24 identify the slot (9) in IO space, A23-A18 are not decoded - any value is fine, so many different addresses will address the same regions of ROM/RAM, and A16 must be set (1). A17 is the critical bit, so if it is 1, ROM OE is asserted. ($f99f0000). If A17 is 0, either RAM OE is asserted or RAM WE depending on R/W signal.

We know ROM access works, because without that the card wouldn't be detected at all. And at least some of the buffers are behaving sanely, because that'd cause the ROM access to have issues: it would fail checksum, and the card would not be further initialized.

If I had this card in hand, my next step would be to poke bytes and words at the aforementioned address using MacsBug. Essentially perform your own memory test - write a byte, see if you get it back, and verify that you can read/write words also. Depending on what you see from that it may give a pointer as to where the issue lays.

Given that the card works sometimes and sometimes not, the simple explanation is a dodgy trace or solder joint rather than a failed IC. May be worth warming the card up or chilling it down before use and seeing if behavior changes. Maybe post some high res well-lit pictures of the card front and back, too? I would recommend looking very closely at U16 and U15.

 

[Reasons.]

Pulled the card out to take some pictures:

Looks like U15 and U16 are socketed on my board--I'm going to remove them, apply some contact cleaner, and reseat them. I doubt it's that simple, but might as well. After that I'll take a look at MacsBug and see where I can go from there. I am somewhat suspicious of the two jumper wires going to U14, but who knows.

Edit: Contact cleaner didn't work, as expected.

 

[zigzagjoe]

Those are nice pictures. Looks like you have an early card. Socketed GALs aren't common and I see the rev is C1. Those bodges look to be of the same style as the factory bodges on the Rev C2 cards that I have. If they are connected on each end, I wouldn't worry about them. I'm not actually sure there's a bodge-less SE30/IIsi maccon, actually....

Still, the symptoms described sound like a bad contact somewhere that the stress of removing/re-inserting sometimes bumps enough to be fine for a bit. It may be worth reflowing the joints for the lower PDS connector as a shotgun approach.

Off-topic, I do enjoy seeing boards with the early "natural" PCB colors.

 

[Reasons.]

Okay, two months later I finally got around to reflowing the solder joints on the connector and it works! I'm going to leave the machine on for a while and keep testing, but I'm hoping this is going to be working for the duration now. Thanks for everyone's help, especially so many years in the future!

 

[zigzagjoe]

Nice! Glad to hear you have it working.