Ignore the sub-microsecond power-up glitch in Saleae timing - #74
Merged
Conversation
Regression from 13b97fb ("Power bench and verify targets from the Otii instead of the ez-FET"): every run now starts from a cold supply, and while VCC ramps P3.4 is high-impedance, so the line follows the rail for ~0.4 us and the extractor counted it as a second start pulse.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Regression
ckpt bench/verifyon any benchmark failed withIntroduced by 13b97fb ("Power bench and verify targets from the Otii instead of the ez-FET"): the target is now powered from the Otii main output, so every run starts from a cold supply. While VCC ramps, P3.4 is high-impedance — the firmware cannot clear
LOCKLPM5and drive it low until the CPU runs — so the line follows the rail across the analyzer threshold. Under the ez-FET the rail was already up whenmspdebugreleased the target, so this pulse never existed.Measured on
build/aes.elf(repeatable to the sample across runs):Start→stop is 25.58 ms on both paths, so only the extra glitch is new.
Fix
Classify a start pulse as
2 µs <= width < 1 ms, in both_extract_timing(bench/verify) and
_replay_timing_from_pulses(intermittent). The nominalstart pulse is 10 µs, five times the floor; the glitch is well below it. The
ambiguity check that catches genuine restarts is unchanged. A pulldown on P3.4
would remove the glitch at the source; this is the software-only fix.
Comments and docs (
benchmark.h,docs/saleae.md,docs/intermittent.md) nowdescribe the glitch, and
docs/saleae.mdnotes that the 10 µs / 5 ms widths arenominal —
_timing_delay_cyclescounts iterations, not cycles, so the realpulses are ~70 µs / ~34 ms at 16 MHz.
Test plan
uv run pytest tests/test_saleae_timing.py tests/test_intermittent.py— 27 passed, including two new regression tests built from the captured waveform.uv run ckpt bench uninstrumented aes --timeout 120→OK compilation_time=806ms execution_time=25551.71us, matching the ez-FET reference.ckpt bench milp crcwas not run:passes/build/CheckpointPass.sois not built in this workspace. The timing path is shared with the uninstrumented run.