Proof-of-concept burn-in procedure

We've succeeded in running a proof-of-principle burn-in at LBL. This burn-in involved running one module in an environmental chamber, logging the module power and temperature in 2-second intervals and executing a list of scans (digital scan and threshold scan) in 2-hour intervals. Hopefully this document will allow others to reproduce our procedure.

Once you've followed the steps in the Quick instructions for getting started on windows section of the AMBuSh documentation page, you should do the following:

1. Check that the SuRF board generates the right clock delay. Connect a module to the SuRF board and power it up; start TurboDAQ; run the TurboDAQ MCC tests with varying delay cable lengths across JP1 on the board and XCkr phases on the TPCC and TPLL. (If you put a jumper across JP1, a TPLL phase of -4 TU and a TPCC phase of -1 TU will get you close to where you want to be.)
2. Restart AMBuSh and restart pontifex.
3. Use the TurboDAQ macro utility to make two primitive lists: one to load a configuration for your module and one to run a sequence of tests.
4. Edit the files sample.script and sample.mod.table to reflect your setup.
5. Hit the "open socket" button in TurboDAQ.
6. Paste sample.script into your AMBuSh window or (if you're running 0.0.9rc10 and my code isn't buggy) say #include sample.script on the AMBuSh command line.
7. If all goes well, AMBuSh will log the module voltages/currents/temperature in TURBODAQ_FILES/MODULE_NAME/data/ambush/. You can use a gentle program like tail -f to read these files as they're being generated (brutal programs might steal the files away from AMBuSh, causing the logging to fail).
8. If TurboDAQ is idle, you can type turbodaq_release(); at the AMBuSh prompt. That will cause TurboDAQ to abandon its socket and return control to the GUI (so you can check if the thresholds from your burn-in scan look good etc). If AMBuSh tries to talk to TurboDAQ while you're playing with the GUI, nothing bad should happen unless too many requests pile up (in which case the OS will kill AMBuSh). (In our burn-in, the requests only arrive once every two hours, so there's no great danger.) When you're done with the GUI, remember to hit the "open socket" button again; TurboDAQ should then start processing the AMBuSh requests it received while it was distracted.

Problems you might encounter along the way:

• Pontifex gets confused. The Pontifex is a very fragile creature. If you notice that the surf commands you're issuing don't make it to the board, you will have to restart ambush and restart pontifex.
• Something clobbers the XCkr delays you painstakingly set in TurboDAQ. If TurboDAQ is tied up because it's listening to AMBuSh, send it a turbodaq_release(). Remember to re-open the socket once you've set the proper values.
• The environmental chamber is controlled separately for now.
• When entering Ambush commands, remember to end with ; and type Enter twice.

Please send problem reports to Johannes.

$Id: poc-burnin.html,v 1.2 2004/03/28 07:25:45 jmuelmen Exp $