jitter/variable delay between trigger and measurements


I am quite new to the Chipwhisperer (lite) and I am trying to reproduce the simple serial aes on a new target board namely a MEGA328P based arduino nano board. I had a few problems with using the external serial and configuring the trigger pin (I will come back to that later when I understand better what is going on).

The main problem I am experiencing currently is that my traces are not aligned properly. I created a .
small video showing what I think is a problem

Here is a screenshot (when trancing the trigger pin)

any hints of what is going on? the is time of the tigger also recoded somewhere in the traces? thanks

One workaround, while you don’t fix it and depending on what you are trying to do, woulld be to open the Analyzer and apply the SAD preprocessing filter. After that you may want to save the traces again using one of the result widgets.

Thank you for the answer. The Sum of differences alignment works well on the traces above but it harder on the actual traces I am trying to capture. I hope to find the reason for this misalignment.

Hi there,

I hope you’re enjoying your ChipWhisperer! Thanks a lot for including a video - it’s really helpful.

Are you capturing the trigger signal (instead of a power trace) in this video? One thing I noticed is that your trigger’s rising edge happens around sample -200 - the trigger goes high before the ChipWhisperer is totally ready to capture anything. This means that the capture is basically starting as early as the ChipWhisperer can manage, which isn’t always at the same time, causing a bit of jitter. Try changing your setup so that the microcontroller has a bit of delay before starting the operation and see if this helps.

By the way, we typically trigger on rising edges to avoid these problems - there’s only one rising edge in your trigger signal, but there are many high samples!

So far so good! I am learning tons of new things and enjoying it so far. Finding my way is a bit hard between the sphinx documentation, the website, the wiki , chipwhisperer.io/ a helping hand (irc?) would be nice.

Indeed in the video I am trying to measure the trigger pin. I want to make sure I am sampling during the aes encryption process and expected (when measuring the trigger pin) to be able to see what part of the traces are of interest. The simple serial AES example script Indeed only starts 1250 cycles after the trigger and I don’t really understand why as in my setup this would be way to late. I am wondering how to proceed. I did not mention this but I am not driving the clock of the victim board (running at 16 MHz) and hope to setup the ADC to sample at that rate.

Simple Serial example code however directly starts encryption after raising the trigger. How come it is not missing the first round of AES?

My assumption until now is that the following is happening

  • Setup triggers (and start sampling)
  • Launch experiment
  • Wait for results

but it sounds like the order might be different

Yeah, this is a problem we’ve had… Our documentation has moved a few times. The up-to-date one is the wiki. We need to eventually migrate everything else over there too.

Your order is right, but I’m thinking that there might be some delays somewhere along the line so that the triggers aren’t totally ready when the operation starts. The problem isn’t the time between trigger-high and encryption-start - the problem is that both of those are happening too soon.

Things to try:

  • Maybe your firmware is putting the trigger high too quickly after it gets the command to start the experiment. Try adding a delay in your code before putting the trigger high.
  • Maybe the trigger signal is getting electrically ruined somehow. Try connecting the capture input somewhere else. The power rail should be fine here - you should still be able to notice any jitter! Also, make sure your ground connections are good.
  • Maybe the CW-Lite’s ADC clock is messing things up. If you can get a clock signal off the Arduino, try connecting that to the HS1 input and change the ADC to use EXTCLK instead of CLKGEN. (The Freq Counter underneath it should confirm to you that the clock signal is okay.)
  • If none of these work, we have some more debugging ideas…