Recommended steps for TraceWhisperer stability?

Embedded Security ChipWhisperer Hardware
1

Hi, I have been using TraceWhisperer on the Husky to record sample times for functions in an implementation in order to create a reference trace. It seems however that capturing the times using “times = scope.trace.get_rule_match_times(raw, rawtimes=False, verbose=False)” will only work occasionally, with less success the longer the loop continues (in the case of setting scope.trace.set_isync_matches() to a set of function PCs in a loop).

For example, the times reported in the long running loop for a particular function are empty arrays, but I can pick out the function specifically and run capture after a reset and receive the proper times from the get_rule_match_times() method.

My question is if there are recommended steps to ensure that I can get times given a loop of around 100 different function PCs? I see on the GitHub for TraceWhisperer that “8Kbytes of traces data can be recorded”, is this cleared programmatically after each capture, or potentially getting overflowed?

In ‘scope.errors’ I get a “ADC errors = trigger too soon error,” which should be related to the behavior I am getting with TraceWhisperer, because my setup works fine with the normal scope.arm().

The code resembles:

scope.adc.samples = int(5e6)
scope.adc.stream_mode = True
timeAndFuncTupleList = []
for i, pcAndFuncTuple in enumerate(pcAndFuncNameTupleList):
    if "my_func" not in pcAndFuncTuple[1]:
        continue

    # scope.io.nrst = 'low'
    # time.sleep(0.2)
    # scope.io.nrst = 'high'
    # time.sleep(7)
    
    funcAddr = int( "0x"+pcAndFuncTuple[0] ,16)
    print(i," of ", len(pcAndFuncNameTupleList), f"{funcAddr:x}", pcAndFuncTuple)
    scope.trace.set_isync_matches(addr0=funcAddr, addr1=0x08003bea, match=0)  # addr1 ignored since we match on 0
    
    time.sleep(0.05)

    scope.trace.arm_trace()
    target.simpleserial_write('m', bytearray())
    target.simpleserial_wait_ack(4000)
    ret = scope.capture()
    if ret:
        print("Target timed out!")
    raw = scope.trace.read_capture_data()
    times = scope.trace.get_rule_match_times(raw, rawtimes=False, verbose=False)
    print(times)
    for trigTime in times:
        timeAndFuncTupleList.append((trigTime[0], pcAndFuncTuple[1]))

I am capturing 1x the chip frequency, which is an STM32F3.

2

I really can’t diagnose the issue without a proper reproducible example.

In the absence of that, in general when working with trace it’s important here to distinguish between TraceWhisperer, which is basically pattern matching logic running on the Husky FPGA, and ARM Trace, which is the vastly more complex thing that’s running on your target. If the capture runs properly after a reset (assuming here you’re referring to a target reset), then that suggests that the reset has caused the target’s trace output to behave differently.

It may be useful to look at the trace output pin with an external logic analyzer.

ADC errors relate only to the power sample capture and have nothing to do with TraceWhisperer; look at scope.trace.errors instead. Any overflow (which can indeed happen) would be flagged there.

Finally, TraceWhisperer has no known issues around stability (or anything else).