Offset and trig_count in scope.adc

Alex051 · March 24, 2026, 9:08am

Hi everyone,

I’m encountering a confusing behavior when using scope.adc.offset together with scope.adc.trig_count for long trace acquisition in ChipWhisperer, and I’d like to ask for clarification.

Background

Initially, with:

scope.adc.offset = 0

I ran my code, observe:

scope.adc.trig_count ≈ 15,000,000

I interpret this as the trigger staying high for about 15 million samples.

My goal is to capture only the last 1 million samples, so I set:

scope.adc.offset = 14,000,000

Observation

After doing this, when I read:

scope.adc.trig_count

I get approximately:

29,000,000

That is:

≈ 15,000,000 + 14,000,000

My confusion

According to the documentation:

offset is the number of samples to wait after the trigger before starting capture

So my understanding is:

offset should only shift where capture starts
It should not change the actual trigger duration

Therefore, I expected:

scope.adc.trig_count ≈ 15,000,000 (roughly unchanged)

But instead it becomes:

scope.adc.trig_count ≈ 29,000,000

Questions

What exactly does scope.adc.trig_count represent?
- Is it the actual trigger high duration?
- Or some cumulative counter (possibly including offset)?
Why does trig_count increase when a large offset is applied, seemingly following:
```
trig_count ≈ original_value + offset
```
Is this expected behavior, or am I misunderstanding how offset should be used?
Does this affect the correctness of the captured power trace?
- In other words, even if trig_count looks different, is the captured waveform still valid (e.g., correctly capturing the last segment)?

I can provide code snippets or more details if needed.

Thanks a lot for your help!

jpthibault · March 24, 2026, 12:34pm

Which version of ChipWhisperer are you using? Run print(cw.__version__) to find out.

It sounds like you’re using an old version which has this bug:

github.com/newaetech/chipwhisperer

scope.adc.trig_count sometimes doesn't get reset

opened 04:32PM - 06 Aug 21 UTC

closed 11:13PM - 06 Jun 22 UTC

jpcrypt

bug

`scope.adc.trig_count` is supposed to count the number of cycles that the target…'s trigger is seen high during a capture (i.e. the length of the target operation). It's supposed to be reset to 0 when the scope is armed, but sometimes that doesn't happen, which means that `scope.adc.trig_count` then shows the number of cycles for the last *two* (or 3 or 4...) captures. This problem exists on the CW-lite and CW-pro. It needs to be fixed in the FPGA Verilog source; until then, a workaround is to do something like this: ```Python initial_trig_count = scope.adc.trig_count trace = cw.capture_trace(scope, target, text, key) actual_trig_count = scope.adc.trig_count - initial_trig_count ``` Then, `actual_trig_count` will indicate the actual number of trigger high cycles, regardless of the FPGA bug.

If that’s the case, upgrading to the 6.0 release should fix the issue.

Alex051 · March 24, 2026, 12:46pm

jpthibault · March 24, 2026, 12:53pm

I can’t replicate the issue.

Can you confirm with an external oscilloscope or logic analyzer how many cycles your target is actually driving the trigger line high?

Alex051 · March 24, 2026, 1:19pm

I cannt sir, are there any other ways to deal with it?I found this problem only on the large program. When I am dealing with program that only has 10k cycles, these things never happen

jpthibault · March 24, 2026, 1:59pm

Again, I expect that your program is not asserting the trigger in the way that you think it is; the easiest way for you to check that is with an oscilloscope or logic analyzer. Otherwise you could use a debugger to learn when trigger_high() and trigger_low() are being called.

You can also do a simple experiment with our simpleserial-aes firmware: in the get_pt() function, wrap the aes_indep_enc(pt) call with a for loop, so that the AES encryption takes a lot longer. Make it take as long as you wish.

Then, capture traces with different values of scope.adc.offset and see whether scope.adc.trig_count remains constant. I did this experiment, and scope.adc.trig_count does remain constant.