Sure, Mouser perhaps shouldn't have blind faith in the "judgement of each and everyone", but how far should one have to go to get satisfaction from a company after paying them a considerable amount of money for a product that doesn't work?
In my case, I spent several hours probing the board looking at voltages, checking continuity from connectors to MCU pins, and I even looked at the Gerbers to see if there were any potential shorts or signals connected to nets they shouldn't be.
Yes, I could have gone further and removed and replaced components to try to troubleshoot the issue, but ultimately didn't for two reasons. Reason one: this board has lots of tiny surface mount parts packed tightly together. Reason two: why should I? This is a brand new board I paid several hundred dollars for, so why should I be expected to debug it on a hardware level, particularly when Mouser could then claim I screwed the board up with my debugging.
While I was typing this reply, someone asked what the problem was. Here's a description. This board is a medium power motor control board that is designed to drive three-phase motors up to 75v and 35A. It has an interface for Hall and quadrature encoders. In the default configuration, the three encoder inputs have 10K pull-ups to Vdd. I connected a motor with Hall position sensors to the board and tested the encoder inputs with some simple code that reads the three inputs and displays the Hall state over a serial port. Rotating the motor's shaft by hand I was seeing only even numbers in the range 0-6. I should have seen even and odd numbers in the range 1-6 (0 and 7 are forbidden Hall states). This implied Hall input #1 was stuck at "0". I know this motor's Hall encoder works because I immediately tested it on another board and saw the expected outputs on its Hall encoder when I turned the motor shaft.
As another test, I disconnected the motor from the board. Since the encoder inputs are pulled up to Vdd, I was expecting to see "1" on each line ("7" when the three where concatenated). I saw "6", again indicating Hall input #1 was stuck low.
The Hall encoder circuit is simple. There's a 10K resistor in-line to limit current, a 10K pull-up to Vdd (3.3v), a 1nF cap to ground to filter noise, and a Schottky diode to Vdd to clamp input voltages to the Vdd rail. Each of these three circuits (one for each encoder input) then goes directly to an MCU pin, which in the input state is hi-Z. When I put 3.3v on the H2 and H3 inputs (the working ones), I saw 3.3v on both sides of the 3.3K resistor in-line from the input to the MCU. When I put 3.3v on H1, I saw 3.3v on the connector side of H1 and 1.25v on the MCU side of the resistor. Probing directly at the MCU pin, I saw the same 1.25v. The MCU's threshold for a logic high is 1.88v, which would explain why I'm always seeing "0" on that input. Something is pulling down that input, but without removing components from the board, it would be difficult to tell what it is.
According to the schematics, there's nothing else connected to this MCU input pin, and I verified this by looking at the Gerbers. I also verified that all three of the MCU ports associated with the encoder inputs are in input mode with the internal pull-ups/pull-downs disabled.