Fried Meilhaus ME-8200 Digital I/O card (WHL #75)
I can’t stand throwing away allegedly damaged stuff without proper diagnosis (or even working surplus items) at work. For today, I took home a pretty nice I/O card for final testing before sadly putting it in the bin. It’s a ME-8200B PCIe card from Meilhaus, a German test equipment specialist. It’s red (which makes it faster), and it retails for 680€ plus VAT at the moment, so certainly not something you’d throw away without second thought. However, due to our overpriced fancy standard clients at work, testing PCIe cards is basically impossible – you can’t do that inside those tiny cases, and I’d hate to completely disassemble one of those things (short cables to fit the envelope!), let alone reassemble it. But at home, there’s a Supermicro X8DTL+ bench/debug table just waiting for such cards…
Story of the card is as follows: Third party builds a measuring system according to our vague ideas, we take delivery, do not check it properly, and some time later decide to finally get it going. It doesn’t work (surprise!). I check that very card and notice it has the daughter board cable attached the wrong way. Of course I turn it around, switch it on, and the computer behaves…oddly. I swear to god, it completed POST but never made it past the Windows login screen. And it never turned on a second time after that
Turns out the folks connected 24VDC to the VCC_EXT pins, which define voltage levels on the I/O ports. That’s correct and as intended. They also decided to connect those 24V to the VCC_OUT pins on the secondary connector – they almost sound the same, right? Well, that’s the logic high level of the TTL ports – five volts max. VCC_OUT is also connected directly to the 5V rail of the power supply via a power connector to the card, literally centimeters away from where the daughter board plugs in. So in effect they wired a reasonably powerful 24V supply directly (2m shielded cable) to the 5V supply of the computer – and plugged it in the wrong way. And since they fully lucked out, those pins of the D-Sub (DB25) connector are actually NC, since they’re placed on the very edge and the card only supplies 20 pins to it. So they did not even damage the TTL ports directly, maybe during tests, dunno. I, on the other hand, turned the connector around and fried power supply, board, SSD and arguably the I/O card. Teamwork
So, diagnostic part – what’s still working, what’s toast?
Let’s start with the overall structure of the card. Thankfully Meilhaus has a block diagram in their publicly available datasheet (excellent!), so I’ll just show a copy here:
Starting from the “PC Interface”, a deliberately vague term since the product is available in PCI, PCI Express, USB and Compact PCI form factors, moving over to “Control Logic Registers” (a FPGA), and then fanning out to one or two (8200 A/B version) 8-bit inputs via optocouplers, one or two 8-bit outputs via optocouplers, as well as two 8-bit TTL I/Os routed via the secondary connector. It says 20-pin IDC as that is what’s present on the main board, but similarly to the DC37 connector there, it’s accessible via a DB25 using a second card slot.
Since the card is still present in the device manager, the PC interface thing likely isn’t completely dead. It can also be accessed via the Powerlab software, but from there the TTL ports cannot be set from In to Out, that results in an error message. Input pins are somewhat static (some move around, most stay at a random pattern) and cannot be changed, output pins do not seem to activate.
Top row is just a bunch of BCP56 transistors (NPN, 1A, 80V, SOT-223-4) with a nice PCB strip for heatsinking, plus (MO)D207 dual-channel optocouplers. There’s nine more of those optos below, eight for addressing the two VN808 octal channel high-side drivers, and one shared for reading their status pins that signal thermal overload. The VN808 are the thick PowerSO-36 units on the left near the DC37 port that also have their tab (VCC!) exposed on the back for better heatsinking. And then there’s the (T)SSOP-48 package horizontally between the optocouplers and the 20-pin IDC connector. That one is an IDT (now Renesas) 74FCT163245CPAG, a “3.3V CMOS 16-BIT BIDIRECTIONAL TRANSCEIVER”. It’s a refreshingly cheap and still available chip at 2.46€ a piece (or half that in 1000-off quantities) and the 3.3V part only applies to interface logic, while all 16 ports are compatible with regular 5V TTL and 3.3V LVTTL.
Moving to the left it gets more interesting: The chip that is rotated by 45 degrees is a PLX (now Broadcom…) PEX8112 PCIe to PCI bridge. So in essence, that card is a copied design from the PCI variant, and it got a bridge chip to offer a local PCI bus. Well, that’s one way to design a “PCIe” card for sure.
The next one in line is the most puzzling to me. It’s a PLX PCI9030 which is advertised as “SMARTarget I/O Accelerator”. Some PLX marketing dude had a wank after coining that term, and honestly, I do not speak PCI fluently and given its age of 30 years, I probably never will. I don’t really know what this thing does and why it is needed – judging from other documents and their product brief, I think this creates a “local bus” system of some capacity that is easier to interface with than PCI itself. So that chip sits in the middle of it and handles all the PCI duties, but can be talked to via simpler protocols that are easier to implement in the FPGA. A 2014 document from Mouser lists prices for both of these chips for MOQ 100 – the PEX8112 is 18 dollars, while the PCI9030 in µBGA is 58 dollars. So even though prices drop further with order quantity, that is a significant chunk of the retail price of the card, and the PCIe interfacing chip isn’t the expensive one out of the two.
And finally, the one chip that does it all – the FPGA on the right. It’s a Xilinx (now AMD, geez!) Spartan-6 XC6SLX9 in FTG256 package. X9 denotes the number of logic cells, that one got 9152, and with that it is almost the smallest one in the series with only the X4 offering less (it ranges up to X150 for comparison). F is the package with the largest ball pitch at 1.0mm, likely the easiest to solder and there are no real space constraints here.
Couple more things: There’s two soldered SMD fuses for the hungry VN808s, an LT1763 (have I complained about mergers already? No? Linear got acquired by Analog in 2017…) low-noise LDO in adjustable configuration, plus a 5-to-7-ish pins package labelled “LDDW 044J” near the FPGA that could be a LTC3025-1 according to the googles. That would fit the voltage requirements since that’s a VLDO (only 85mV drop at half an amp!), again in adjustable configuration. Both LDOs can be had in fixed versions with exactly the voltages specified, so that’s an odd design decision. The LT1763 runs with 270 (“271”) vs 1210 ohms (“1211”) so that’s 1.492V according to the datasheet (1.5V part available), and the LTC3025 does 80.2k (“88C”) vs. 40.2k (“59C”) which yields 1.202V, 1.2V versions are available.
Additionally, there are two firmware memory modules present, an ST M93C66WP 4KiB SPI EEPROM closest to the PCI chip as well as a Xilinx XCF02S 2Mb/256KiB NOR flash near the FPGA. Both run with non-5V supply voltages (2.5V and 1.8-3.3V respectively).
Enough of that listing – tell me the fault, son!
I have no clue. Starting from the latter parts, both Flash and EEPROM do run with converted voltages. Sure, the LDOs involved could have gone way over their specced voltage during that 24V supply surge and survived, but that requires desoldering and testing both parts. I have ordered a programmer very recently (the XGecu T48, technically a TL866-III that isn’t exactly widely reviewed yet), but right now it does not support the Xilinx part. The small EEPROM only has 135 bytes of what looks like binary config data on it – that’s not a lot, is it. But it does read fine and there’s hope the XCF02S has survived as well.
Voltages are correct. Of course there’s 5V and 12V present, there’s 3.3V from the PCIe connector, and there’s 1.5V and 1.2V from the LDOs. There’s also still 5V on the IDC connector, meaning the 24V high-amp episode did not blow up the track on the PCB and it still connects directly to the Molex connector of the PC power supply. Both fuses are intact as well, but they can only blow from external short-circuits on the VN808s, no surprises here.
Speaking of the VN808 chips, both of them do not produce any output signal regardless of software settings with 24V applied to the input voltage pins. As I said, the fuses are fine and so are the reverse voltage protection diodes, the PCB tracks to the DC37 are also perfect, but there’s no output signal. Looks like a “no input, no output” situation to me – D_out A0-A7 and B0-B7 gone. Similarly, the top row optocouplers (D_in A0-A7, B0-B7) do produce voltage changes when something is applied to those inputs, and those pins directly connect to the FPGA as well – they’re simply not recognized. And TTL signals fed via the 20-pin connector do arrive at the 74FCT163245CPAG (all paths tested), but that chip seems stuck in an undefined input/output mode and there’s no voltage output and also no reaction to voltage input. It’s directly connected to the FPGA as well.
Which leads me to the sad, sad conclusion that our friend from Xilinx likely has a direct reference to the 5V rail, maybe a resistor divider tap or something for a general power-good check, and that one got 5x the expected voltage for more than a minute. Poof, unknown amounts of magic smoke might have been displaced from an area where they are needed the most…although the package is intact.
Now would be the time to get that part off the board and a spare from eBay back in, but with a 256-ball footprint (despite the generous 1.0mm pitch!), that probably won’t happen. One does not simply reflow BGAs at home…and especially not ones that set you back 100€+ at the moment, since the reputable suppliers like Mouser, Digikey and Bürklin declare zero stock for those ~50€ parts. Without the proper equipment at hand and a known-good state of the NOR flash, that’s not worth the risk – after all, I’m doing this for the lulz in my free time and with my own money.
Time to bin it, sorry