A lot goes into bringing up a new design. You typically think that everything was reviewed and double checked during design phase, but then something happens during the time when the board is sent off and when it is received. Having the project canceled (leaving you with empty PCBs) to a simple BOM change (easiest) are just a few things that can happen.
I will review a new board that I brought up recently; it was the first version 1.1 (1.0 was never built) when it arrived which is the hardest to bring up. These are the steps followed:
1. Visual inspection, usually under magnification. Did the board manufacturer build it correctly? Is it sloppy? Silkscreen readable? Are edge cuts far enough from traces? Copper properly tinned?
2. Check the power supply rails. Are there hard shorts (before and after assembly)? Is the correct voltage at required pin locations (before and after assembly)? Check the ripple at voltage in for the components once assembled.
3. Check the clocks. Are they at the proper voltage that the parts require? Frequency? Jitter?
4. Create a plan to test as you assemble; start with center of design and move out. Processor or FPGA working? Then is I2C eeprom working? Is SPI eeprom working? Is more complex SPI peripherals working?
5. More in-depth testing. Can you Read and Write eeproms? Can you send a packet? Can your RAM pass memory testing routines.
6. Final system integration testing. Can the full software and hardware stack run properly? Does long term testing pass? Does thermal, shock testing, etc (if needed) pass?
At the end of your testing you will have a list of issues and a log of what happened.
The issues (bugs, failures) are tracked so that as they are identified (and fixed), An example of simple spreadsheet tracker Bringup Issue Tracker usually has a short description, long description, date opened, severity, open/closed/deferred and category (software, hardware, board, schematic). Complex systems can be a dedicated database with web front-ends that can create reports for management.
The bring-up log allows everyone to follow what is happening during bring-up an allows you to easily review things that you've tried in the past the worked or did not work. The Bring-up Log in this case was a Google Doc that allowed me to keep track of results, brainstorm and all the steps. More complex systems can use Wiki's or other type of dedicated database (reports and such).
This project started with a bare board and a bag of Digikey parts. I was able to build-check-go as I went. This allowed me to start at the center of the design and work my way out the the peripherals of the design, developing new tests as I went. Sometimes the test worked sometimes not, but I was always moving forward. If the test didn't work I had to develop a "Plan B" until I could get that part of the design tested.
It was a long and difficult process, but in the end I was confident that everything I tested would work in version 1.2 (version 1.0 was never built). The next version should be easier, because tests are already created and the only new test to be made is the one part of the design I could not test because of a really-really bad board issue.
Let me know if this helped or if you need help bringing up a new board.
