Checking power-up timing against a datasheet

Two traces, one fairly ordinary question.

I started with an ESP32-C3 development board. I had the 3.3 V rail on one scope channel and CHIP_EN on another. The waveforms looked straightforward: power comes up, then the enable signal changes.

But looking right isn't the same as meeting the datasheet. Where exactly should I measure the start of the delay? Which voltage counts as the release threshold? And if I change something on the board, will I use the same thresholds next time?

I can answer those questions with the scope's cursors. For one capture, that's fine. For repeated checks, I'd rather save the rules once and run them against the next capture. I could write a Python script for the board, but then the thresholds, channel names and acceptance criteria tend to get buried in that script.

I didn't need another oscilloscope.

There is already good software for power measurements. Tektronix and Keysight offer much wider analysis workflows, including sequencing, ripple and switching measurements. That makes sense when you need those tools. I was only trying to check a couple of limits from a saved capture. I didn't want to build another measurement suite around that. A small tool that works with exported data and keeps the checks separate from the oscilloscope software felt like enough.

A Python library such as Oscura can help load and analyse waveforms. But it still leaves me to decide how my particular datasheet requirement becomes a test, and what result to report when a measurement isn't available. A Saleae article about power-rail sequencing discusses a similar need for automatic requirement checks.

I'm not claiming nobody has solved this. Hardware teams write these checks all the time, often as part of a bigger test setup. I think the awkward part is the handoff: the scope gives you samples, analysis code gives you measurements, and the datasheet gives you the limits. For my use case, I wanted those last two pieces written down in a form I could review and reuse.

A boring example: an ESP32-C3 board.

The ESP32-C3 datasheet uses 2.8 V on the supply rail as a timing reference and requires at least 50 µs before CHIP_EN is released (Section 2.5.3, Figure 2-4 and Table 2-11 in v2.4). The release threshold is given as 0.75 × VDD. With a nominal 3.3 V supply, that's 2.475 V.

So I need two events: the rail crossing 2.8 V and CHIP_EN crossing 2.475 V. The delay between them must be at least 50 µs. Here's the part of the contract that expresses that:

events:
  vdd_timing_anchor:
    signal: vdd_3v3
    direction: above
    threshold: 2.8
  chip_en_release:
    signal: chip_en
    direction: above
    threshold: 2.475

requirements:
  - id: ESP32C3-PWR-001
    type: delay
    from: vdd_timing_anchor
    to: chip_en_release
    min: 50us

The complete example also maps the channels and checks the supply-voltage limits. The thresholds here come from the datasheet; PowerContract doesn't extract them automatically. It finds the crossings in the captured samples and interpolates the times between them.

This is a chip-level example, not a claim about the 5 V input or regulator on a particular development board. And the fixed 2.475 V threshold assumes nominal VDD; it doesn't follow a changing supply. Those assumptions belong in the test definition.

What if the capture doesn't show the event?

Say CHIP_EN never crosses its threshold in the recorded window. I can't calculate the delay. That isn't evidence that the 50 µs requirement passed, but it isn't a measured timing failure either. I need a third answer: INDETERMINATE.

Uncertainty causes a similar problem. Imagine a 3.60 V maximum with a measured peak of 3.58 V and a declared uncertainty of ±0.03 V. The possible interval is 3.55–3.61 V. It straddles the limit, so I can't honestly call it PASS or FAIL.

PowerContract uses the uncertainty I put in the contract; it doesn't estimate it from the noise in the trace or guess what probe I used. The reported margin accounts for that declared uncertainty. If I haven't established something from the data, I'd rather see that in the result than get a confident-looking answer based on an assumption.

Same rules, another capture.

The workflow I had in mind is uncomplicated. Export the waveforms, give the signals names, keep the requirements in YAML, then run the check. If the circuit changes, take another capture and run the same contract again.

powercontract check capture.csv power.yaml --json report.json

The simplest input is one CSV with time and signal columns. My first captures came as separate files for each channel. That raised another question: how do I know the files belong to the same acquisition? For the supported per-channel format, the parser checks the metadata and time axes before combining them. Other CSV layouts have their own loaders and tests. The input-format guide lists what is supported and what has been tested with hardware.

The scope doesn't need to be connected to the machine running the check. It just needs the recorded data and the same contract I used last time.

A pass only covers the measurement I made.

If a check passes, it means the recorded waveform met that requirement under the thresholds, time window and uncertainty I specified. It doesn't prove that every power cycle will behave the same way, or that the board is fine at every temperature and load. Bad probing or inadequate sampling can still give me bad evidence.

I'm happy to leave capture, stimulus and detailed signal analysis to the tools that already do them. What I wanted from PowerContract was just a consistent way to put a datasheet requirement next to a measured waveform and record the answer.