The next step after powering up the boards is to exercise them.
This means installing the ESP32 and using a minimal piece of code to set all the pins to safe states, then to start setting pins to known states and making sure that the pins drive and that the pin goes to the correct place and checking with an Oscilloscope (scope). This helps in validating that the board is defect free, with no short circuits and no open circuits.
Once the confidence is there that all the pins are driving as expected, then the proper code - which is still not ready at this point, can then begin to be used.
I started with the SPI decoder and all the normal output pins, which there are not very many of, since most of the general purpose IO pins (GPIO pins) are off of Microchip MCP23S17 16-bit IO Expanders with SPI interfaces, there are two interrupt pins that can be configured in different ways depending on what I need. This in turn means that the SPI bus, the interrupt pins and the I2C bus go across much of the board, connecting up to the relevant IC's. Test pins are also present next to the ESP32, so that I can connect these to my Saelae Logic Analyser, which is worth its weight in gold when working on protocol or more than a couple of signals at the same time. If you enjoy this sort of hobby or are in studying Electronics at college or university, then give them a call and ask about their hobby and educational discounts, you might be pleasantly surprised.
Testing did not go well when I got to the SPI bus, it wasn't working as expected and that meant that the IO expanders could not be tested and therefore much of the IO wasn't working. Probing with the scope showed the bus was not working as expected. The multimeter showed a low resistance of a couple of ohms between two pins - not a short, but very close to it. Nice, this goes all over the board.
After a thorough visual inspection under my magnifier, there were no signs of it. I got the other board out, since that is part of the value in having two or more boards during testing and that one worked as expected, so it wasn't a design issue, it was a manufacturing issue, an assembly issue or perhaps a bad chip ?. Now to locate it and sort it out. I used my multimeter on its lowest ohms setting and zeroed out the leads, so that I can measure the small changes in resistance, it gets smaller when you get closer to the problem. I narrowed it down to one part of the board, where there were a couple of chips. Out comes the hot air soldering iron and one chip is removed with the help of a bit of flux and the problem remains. Nice, a 50-50 percent chance of finding it and its the other one. Pop that one off in the same way and the problem disappears. Inspect the chips, they are fine, re-apply both and the problem is no longer there, so it must have been a little bit of solder from initial assembly that didn't flow properly.
An hour or so wasted, but at least the problem is fixed and we can get to talking to the IO Expanders and talking to all the remote IO pins that they control.
Once that was done, the I2C bus was exercised and it was working for the I2C multiplexer and PWM controller, I can't test the differential bus drivers yet, since the remote modules haven't been tested.
Filled with confidence that at least the core of the board was working, I now really needed the main code base to be available, so work transitioned to getting that going, since it now blocked further testing and any work on the other two modules and spring is nearly upon us.