Burn-In Testing for Electronics: A Complete Guide
Burn-in testing operates products under stress for an extended period to catch infant mortality failures before they reach customers. It's the hardware equivalent of "let it run overnight and see if it crashes." TofuPilot tracks burn-in results alongside your other production tests for complete unit traceability.
What Burn-In Testing Is
The bathtub curve describes electronic failure rates over time:
- Infant mortality (early life): High failure rate, decreasing. Caused by manufacturing defects, weak solder joints, marginal components.
- Useful life: Low, constant failure rate.
- Wear-out: Increasing failure rate at end of life.
Burn-in targets the infant mortality region. By operating the product under stress for hours or days, you accelerate the aging process and force weak units to fail in the factory instead of in the field.
Burn-In Parameters
| Parameter | Typical range | Purpose |
|---|---|---|
| Temperature | 55-85°C (elevated) | Accelerate thermally-activated failures |
| Voltage | 10-20% above nominal | Stress power supply and regulators |
| Duration | 24-168 hours | Enough time for weak units to fail |
| Monitoring interval | Every 1-4 hours | Catch failures as they happen |
| Functional check | Before and after, plus periodic | Verify unit still works |
Setting Up Burn-In with TofuPilot
Pre-Burn-In Functional Test
Always run a functional test before burn-in to establish a baseline.
from tofupilot import TofuPilotClient
client = TofuPilotClient()
def pre_burn_in_test(serial):
vcc = measure_voltage()
current = measure_current()
temp = measure_temperature()
client.create_run(
procedure_id="BURN-IN-PRE-CHECK",
unit_under_test={"serial_number": serial},
run_passed=True,
steps=[{
"name": "Pre-Burn-In Baseline",
"step_type": "measurement",
"status": True,
"measurements": [
{"name": "vcc_3v3", "value": vcc, "unit": "V", "limit_low": 3.25, "limit_high": 3.35},
{"name": "current_ma", "value": current * 1000, "unit": "mA", "limit_low": 30, "limit_high": 60},
{"name": "board_temp_c", "value": temp, "unit": "°C"},
],
}],
)Periodic Monitoring During Burn-In
Log measurements at regular intervals during the burn-in period.
import time
def burn_in_monitor(serial, duration_hours=48, check_interval_hours=4):
checks = int(duration_hours / check_interval_hours)
for check in range(1, checks + 1):
elapsed = check * check_interval_hours
# Measure without removing unit from burn-in chamber
vcc = measure_voltage()
current = measure_current()
temp = measure_temperature()
passed = 3.20 <= vcc <= 3.40 and current * 1000 <= 80
client.create_run(
procedure_id="BURN-IN-MONITOR",
unit_under_test={"serial_number": serial},
run_passed=passed,
steps=[{
"name": f"Hour {elapsed} Check",
"step_type": "measurement",
"status": passed,
"measurements": [
{"name": "hours_elapsed", "value": elapsed, "unit": "h"},
{"name": "vcc_3v3", "value": vcc, "unit": "V", "limit_low": 3.20, "limit_high": 3.40},
{"name": "current_ma", "value": current * 1000, "unit": "mA", "limit_high": 80},
{"name": "chamber_temp_c", "value": temp, "unit": "°C"},
],
}],
)
if not passed:
print(f"FAIL at hour {elapsed}: {serial}")
return False
time.sleep(check_interval_hours * 3600)
return TruePost-Burn-In Functional Test
After burn-in, run the same functional test as before. Compare pre and post measurements.
def post_burn_in_test(serial):
vcc = measure_voltage()
current = measure_current()
client.create_run(
procedure_id="BURN-IN-POST-CHECK",
unit_under_test={"serial_number": serial},
run_passed=True,
steps=[{
"name": "Post-Burn-In Verification",
"step_type": "measurement",
"status": True,
"measurements": [
{"name": "vcc_3v3", "value": vcc, "unit": "V", "limit_low": 3.25, "limit_high": 3.35},
{"name": "current_ma", "value": current * 1000, "unit": "mA", "limit_low": 30, "limit_high": 60},
],
}],
)Analyzing Burn-In Data
Pre vs. Post Comparison
TofuPilot lets you compare pre-burn-in and post-burn-in measurements for the same unit. Look for:
| Change | What it means |
|---|---|
| No change | Unit is stable, burn-in passed |
| Small shift (< 1%) | Normal thermal aging, acceptable |
| Large shift (> 5%) | Component degradation, investigate |
| Failure during burn-in | Infant mortality defect caught |
Burn-In Failure Rate Tracking
Track the percentage of units that fail during burn-in over time.
| Month | Units burned in | Failures | Burn-in failure rate |
|---|---|---|---|
| Jan | 1,000 | 8 | 0.8% |
| Feb | 1,200 | 12 | 1.0% |
| Mar | 1,100 | 25 | 2.3% |
If the burn-in failure rate increases, something changed in your manufacturing process. The burn-in is doing its job by catching these defects, but you need to find and fix the root cause.
When to Skip Burn-In
Burn-in costs time and money. Not every product needs it.
| Factor | Burn-in recommended | Burn-in optional |
|---|---|---|
| Safety-critical product | Yes | |
| High field failure cost | Yes | |
| Mature, high-yield process | Yes | |
| Consumer electronics (cost-sensitive) | Yes | |
| Medical/aerospace/defense | Yes |
Use TofuPilot data to make this decision. If burn-in catches 2% of units and field failure costs $5,000 per incident, burn-in pays for itself. If burn-in catches 0.01% and field failure costs $50, it doesn't.
Burn-In Rack Monitoring
For high-volume burn-in, you may have racks with dozens of units burning in simultaneously. Monitor them all through TofuPilot.
Each slot in the rack uploads periodic measurements. The dashboard shows:
- Which slots currently have units
- Current temperature and power consumption per slot
- Any failures that occurred during the burn-in period
- Historical burn-in yield per rack position (catches rack-specific issues like bad power connections)
If rack position 12 has a higher failure rate than other positions, the rack needs maintenance, not the product.