Mainly, the prototype hardware for a big project arrived - shipped from, apparently, China on Tuesday, and I got my hands on it Wednesday. That meant:
Which went well; on application of power, the regulated voltages came up as they should, and there was no smoke to be seen.
The on-board MCU, which handles supervisory functions, programmed normally via the Tag-Connect footprint (once I removed the solder; I'd already corrected the library footprint to turn off solder paste and include "finish" (i.e., gold if available) on those pads, but I did that after the Gerbers went out.
Then, various sorts of functional tests. Normal operation involves a System-On-Module (from Olimex), running Linux, but I don't want to rely on that just yet. So, test the USB hub and peripherals, I chopped the "B" connector off a USB cable, added a connector to mate with the applicable SOM header, and plugged it into my workstation.
Success! Everything seems to come up OK, at least to a first approximation.
Then it's time to plug in the SOM. Hook up a serial cable for the Linux console. Insert a memory card with the latest image from Olimex.
Well... it boots, but I can't seem to get the configuration right. It's not finding the USB, and the Ethernet isn't working - when I plug in the cable, the LEDs come on, but there's no communication between SOM and PHY, for some reason. Grrrr.
Try the previous-edition Linux image. Not much better.
Fiddle some more. Look closely at the schematic, and realize that I've swapped USBD+ and USBD- between the SOM and the hub. Wait, then how did it work with the hacked cable? Maybe the cable has the colors swapped, and the errors canceled out?
With the aid of a couple of patch wires, I get something that looks a little more promising, but Linux is still not finding the high-speed hub. Look at the schematic again. USB1_ID is pulled down with a 10K resistor, same as in the eval-board schematic. But! Digging through layers of documentation until I get to the processor chip's datasheet, I find that the USB ID pin should be either basically open or basically shorted to ground. So maybe the eval board really has 10Ω there, not 10K? Remove the resistor, substitute a solder blob, and hooray! The hub (2 chips, cascaded) and the supervisory MCU enumerate!
Alas, the Linux image I'm using now (I think I was back to the current edition at this point) doesn't include the cdc_acm driver, so I can't actually talk to the MCU.
Next morning, fetch from the client the eval board and the as-edited Linux image that their software guy was using to talk to the first-edition (lash-up) prototype.
USB enumerates, I can talk to the MCU, and things seem to be working! Yay!
But still no Ethernet. In fact, I'm no longer getting so much as a LINK light. Eh?
Grab a USB Ethernet dongle, plug it into the workstation's hub, and try connecting to that. Link light, speed light, and, hey presto!, communication! Must be something's gone wrong with the cable and/or port that I was trying to use.
A bit more fiddling, and more of the board (as much as I've managed to test so far) is working.
'Tis unfortunate that it has those two little patch wires, but such is life. Minor rework on the five prototype units is no big deal. The main board will need a respin anyway, for mechanical reasons: the power connector and the Ethernet connector are both turning out to have Issues with regard to the height of the board stack, the depth of the enclosure, and cable bend radii.
Also, there's a rogue signal trace that I somehow missed seeing in the artwork, reducing the available copper for one of the high-current paths. I may have to stick a bus-bar on that part of the board (which was designed to accommodate bus-bars, just in case).
Hey, as long as the prototypes get through their functional & environmental tests without too much more rework, a few fiddly & localized changes to get to the production model won't be much of an issue.
This is the good sort of project: not only do I get to do cool stuff, but if the product becomes a commercial success (it's primarily for the client's in-house use, but is potentially a product in its own right), there'll likely be a fair amount of follow-on work over the coming years.
Update: Initialization of the SOM is a bit odd; seems the two Ethernet ports share a MAC address (which doesn't really matter, as they wouldn't ordinarily be plugged into the same LAN, and besides the actual application board only has one PHY and connector), and the persistent-net.rules file starts out configuring eth0 and eth1 based on the MAC address of the board on which was originally created... but if you move the memory card (or copy the image) to a different SOM, lines will be added to that file to configure the newly-discovered ports as eth2 and eth3. This is presumably iterative.
So, the master image will need the rules cleaned up, so that whatever SOM it's booted up on will end up with eth0 and eth1, whereof only eth1 is actually functional.
But that's software stuff. The hardware is what I'm meant to be bringing up at this point.
I still need to do the great test of power handling. Actually, multiple tests. Does the master power switch remain reasonably cool while carrying 20 Amps? Do the per-channel switches properly handle 1 Amp each? Do I have enough copper to distribute the current? Will the heavy copper of the inner layers do a good enough job of distributing the heat away from the hot spots?
On this last point, I have some confidence: after the USB hub (high-speed, two 7-port chips) enumerates and starts consuming power, the entire board becomes somewhat warm. The power switches are more obvious hot-spots, but they shouldn't be dissipating much, as the FETs were chosen for, among other things, low ON resistance. Still: maximum total dissipation in the power-path components is around four and a half Watts, and then there's the resistance of the copper itself to be taken into account.
Hm. For a full-load test, I'll need a many-channel dummy load that can handle a whole bunch of Watts. Probably waterproof a bunch of resistors and stick 'em in a cauldron of water. Easier than bolting them to a tunnel-style heatsink (assuming I could find one!) and sticking a fan on it.