Problem using offset to capture long traces

I’m trying to capture some traces longer than 24000 samples using CW-lite. Do do so, I’m repeating the same operation more than once, using the ADC’s offset parameter to acquire different portion of the trace. This normally works fine, but in some cases I’m getting abnormal traces:

Plotted 1 sample out of 10, so the trace are fine for the first 24000 samples, the problem lies with the second portion acquired with an offset.

I’m also getting these errors during the acquisition, I’ve never got them while not using offset:

The code I’m using:

def capture_long_trace(scope, target, adc_samples, text, key, j):

while True:
    scope.adc.offset = 0
    if scope.adc.offset == 0:

while True:
    trace = cw.capture_trace(scope, target, text, key)
    if trace is not None:
    print(f"'None' trace returned for first segment of trace n.{j}")
tot_len = scope.adc.trig_count

if tot_len <= adc_samples:
    complete_wave = trace.wave
    n_acquisitions = ceil(tot_len / adc_samples)
    complete_wave = np.empty((0))
    complete_wave = np.concatenate((complete_wave, trace.wave))
    for i in range(1, n_acquisitions): 
        offset = adc_samples * i
        while True:
            scope.adc.offset = offset
            if scope.adc.offset == offset:
        while True:
            trace = cw.capture_trace(scope, target, text, key)
            if trace is not None:
            print(f"'None' trace returned for {i}th segment of trace n.{j}")
        complete_wave = np.concatenate((complete_wave, trace.wave))
return complete_wave, tot_len

Doing the following to be sure that the offset is correctly set but it does not help-

        while True:
            scope.adc.offset = offset
            if scope.adc.offset == offset:

I’m attaching the entire jupyter notebook. (261.8 KB)

Any idea why this happens?

Note: I’m using AES to show you the problem, but I need this to capture long RSA traces.

Hmm, I’m not getting the “Trigger not found” message when I run your notebook.
Do you get it on a fresh run of the notebook? I’m not sure about that one, but maybe resolving the other issues will take care of it for you:

One issue I see is that you’re not setting scope.adc.samples to adc_samples, so everything is going to be off. Also, it would be a good idea to put a sanity check around tot_len = scope.adc.trig_count, and really, since it’s supposed to be constant, it’s best to get that information only once at the beginning and then use it for the rest of the captures.

Here’s a simpler offset capture function that I’ve used without any problems for > million cycle captures, adapted from the demos/CW305_ECC.ipynb notebook; give that a try on your system:

scope.adc.samples = 24000

def get_traces(N=50):
    traces = []
    segments = math.ceil(TOTAL_CYCLES / scope.adc.samples)
    for i in tnrange(N, desc='Capturing traces'):
        scope.adc.offset = 0 
        wave = np.array([])
        for j in range(segments):
            ret = cw.capture_trace(scope, target, text, key)
            if not ret:
                print("Failed capture")
            wave = np.append(wave, ret.wave)
            scope.adc.offset += scope.adc.samples

        traces.append(Trace(wave, ret.textin, ret.textout, None))

    return traces

Hi, thank you for your answer.
I’m assigning adc_samples to scope.adc.samples in the notebook cell before the while loop with my function, shouldn’t it be ok?
Regarding tot_len, I need to capture XMEGA RSA traces and they have different length depending on the inputs, so I was experimenting with adjusting the number of segments to capture for each trace. I’m also having problems achieving that, since scope.adc.trig_count sometimes return double/triple the expected value (atm I’m testing the code with constant inputs so it’s easy to spot when this happens).

Unfortunally I’m getting the same “fewer points” error with your code. In this case it stops the capture.

Managed to capture a few hundred traces without getting the error but with the same problems:

Something is wrong with my setup, I guess. I’m connecting CW to my laptop through two USB hub due to this compatibility problem I have, I wonder if this could be related.
I’ll try running the code on a clean install and on a different PC.

I did some other tests.
I installed the VM version of ChipWhisperer on the laptop I was having the bug on (Dell XPS) and the code runs fine on it – previously I was using the Windows Installer version.
On a second laptop w/o the USBC compatibility issue the script runs without errors on both the Windows Installer and the VM versions.
The bug only happens on my Dell XPS using the Windows Installer version of ChipWhisperer.

What’s usually the recommended version of CW to use between the two?

I’ve also noticed that, even when the code runs without errors, the value returned by scope.adc.trig_count is sometimes wrong (an integer multiple of the expected value is returned). You previously suggested me to put a sanity check around that value, is there any known bug around it?

Hmm, with regards to that Windows installer version I have to defer to @Alex_Dewar; I’m not aware of any issues that would explain what you’re seeing.

With regards to scope.adc.trig_count, it’s been reliable for me in the past (e.g. for the CW305 ECC demo, the target operation is constant-time, and that property is checked for every single trace).

But I think that the way I measured the cycle count may have side-stepped the issue that you’re running into. Can you see if you get proper cycle counts if you do it this way:
(e.g. measure scope.adc.trig_count before and after the target operation; take the difference).

If so, I think I understand what the problem is – trig_count is supposed to get reset to 0 every time the scope is armed, but sometimes that doesn’t happen.


1 Like

Hi Marco,

Do you know what version of the VM and the installer you’re using?


I’ve confirmed the scope.adc.trig_count problem on my side and created an issue:

To properly fix this, an update to the FPGA bitfile is required, and I’m not sure when we’ll get around to that because changes to the CW-lite bitfile in particular can be troublesome.

But the simple workaround that I mentioned seems to work well – let us know if you still run in to the problem. Thanks for finding this!

@Alex_Dewar At the moment I’m using version 5.5.0 of the VM and version 5.6.0 of the installer. When I first noticed the issue I was using version 5.5.0 of the installer and I’ve later installed version 5.6.0 trying to solve the issue. Thank you.

@jpthibault The workaround works well indeed. Thank you.