On 10/05/11 14:13, Mike Harrison wrote:
> For small runs I usually find it easier to get the boards back as-is and =
program/test myself - it's
> typically way quicker than documenting the process. You ideally need to h=
ave tested a reasonable
> number yourself to get an idea of typical problems and symptoms, to gener=
ate useful faultfinding
> guides. If you're doing something that will be in long-term production, a=
 good approach is to test
> the first batch yourself so you can give the manufacturerer a more useful=
 test setup for future
> builds.

My test procedure (derived from a dozen prototypes, one complete=20
write-off, eleven usable) is -- roughly:

   * Power up with a 50mA limit and 3V supply. Ramp the voltage up to=20
about 9V. Abort test if current exceeds 50mA at ANY point in the=20
testing. Confirm that 5V, 3V3 and 1V2 are within range (5%).

   * Install BOOT jumper. Connect PIC programmer via Millmax header.=20
Increase current limit to 500mA and program PIC with Bootloader and=20
initial firmware image. Check that MCU STAT LED is blinking rapidly.=20
Disconnect power and programmer, remove jumper, power up from standard PSU.

   * Connect to PC. Put hardware into "Secret Squirrel" (Production Test=20
and Debug) mode. Run full suite of tests:
     * FPGA programming
     * FPGA <=3D> MCU communication
     * Static RAM test
     * Board-mounted LEDs and jumpers
     * I/O test (requires switch-and-lamp test board)
     * Final read-write test (connect a cable kit and drive, see if the=20
read-write and seek circuitry works).

A complete test takes a couple of minutes, and the Python script I'm=20
using auto-detects new hardware, runs the tests and assigns and records=20
the board serial number if the tests pass. It's entirely possible (in=20
theory!) to hook up a USB hub and run multiple board tests at once, but=20
I haven't tried that.

All I'd expect an assembler to do is the power test... as long as the=20
power comes up, it's reasonable to expect that the board is at least=20
borderline functional and -- at most -- needs a few opens resoldering=20
around the FPGA bus, I/O buffers or SRAM.

The tests have advanced to the point where they can detect individual=20
stuck bits on the SRAM address and data bus, and single or multiple=20
stuck bits on the FPGA comms bus. This has proven extremely useful when=20
building the prototypes!

--=20
Phil.
piclist@philpem.me.uk
http://www.philpem.me.uk/
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.