Glitch lags after trigger by ~800 ns, no matter what settings used

Embedded Security ChipWhisperer Hardware
1

I noticed my glitches are significantly delayed, around ~800 ns, and I don’t understand why.
I’ve tried to go through all the settings and try them out, but can’t figure it out for simple TIO4 trigger with simpleserial-aes on CW308 target STM32F415 (F3 or ATSAM shouldn’t be different).

This is just slightly modified demo of “02 Husky Triggers” with minimal code to show what’s happening, I’ll add the notebook
husky_glitch_800ns_delay_ipynb.zip (3.5 MB)

Setup - basic with AUX as HS2 output for oscilloscope

I’ve tried different ADC multipliers, but that didn’t help. Usually clock I need is similar to what CW uses (7.37 MHz or 8 MHz to emulate crystal on board). Program the simpleserial-aes demo for STM32F415.

image
image1093×559 89.9 KB

Glitch setup

Tried various settings in the docs, glitch_only/enable_only, changing offsets… according to the glitch network picture

image
image1184×673 88.3 KB

Simple trigger from TIO4 like in demo

image
image1099×519 66.7 KB

Result

First one is with glitch_only, second one is with enable_only.

  • CH1 yellow - HS2 clock from AUX
  • CH2 cyan - glitch out
  • CH3 magenta - TIO4 trigger
  • CH4 blue - from CW501 differential probe

(some signals look a bit dulled since I needed them to terminate with 50 ohm, esp for CW501 to match impedance)

However no idea why the glitch (cyan) comes ~800 ns later than trigger (magenta).

DSRemote_40_STM32F415-AES-sample_800ns-glitch-delay_glitch-only_with-HS2-clock
DSRemote_40_STM32F415-AES-sample_800ns-glitch-delay_glitch-only_with-HS2-clock800×480 15.6 KB

DSRemote_39_STM32F415-AES-sample_800ns-glitch-delay_enable-only_with-HS2-clock
DSRemote_39_STM32F415-AES-sample_800ns-glitch-delay_enable-only_with-HS2-clock800×480 15.1 KB

Trigger network part seems right, though

When I switch the Trigger/Glitch out to show trigger, it correctly shows the trigger at about same time as TIO4 (trigger out = cyan, TIO4=magenta)

DSRemote_37_STM32F415-AES-sample_800ns-glitch-delay_glitch-only-with-repeat_showing-trigger
DSRemote_37_STM32F415-AES-sample_800ns-glitch-delay_glitch-only-with-repeat_showing-trigger800×480 15.5 KB

I have no idea where is the bug, since 800 ns is around 1.25 MHz which is very slow. But also the “Validation” part of “03 Husky Glitching” always fails for me, if it might have to do something with it:

image
image1162×752 103 KB

2

The glitch doesn’t instantaneously follow the trigger; there is a latency of 5.5 cycles of the scope.glitch.clk_src clock, which is exactly what you’re seeing. If you need the glitch earlier, you can either increase the frequency of that clock, or generate the trigger earlier.

Regarding the “Validation” part of the notebook failing: this is probably due to you running the previous cell that turns off the LA and glitch modules. The instructions say to do this only if you’re done :wink:

3

I must admit I don’t much understand why the 5.5 cycle latency happens, why that depends on scope.clock.clkgen_freq, I originally thought MMCM was some separate part. I tried to look at the HDL sources, but without Vivado it’s just some generated files.

Maybe some direct question is better:

  1. I’d like to use usually 8 MHz as input clock in place of the crystal oscillator, without changing target’s source/binary
  2. I’d like if the glitch happened very quickly after trigger (order of nanoseconds), I am mostly interested in SAD trigger (or multi-SAD)

Is that possible? Would it require some extra circuitry for clock division? Any other workaround?

4

Some latency is unavoidable. As I said you can move the trigger earlier to compensate.
If you’re using SAD triggering, then you can simply shift your SAD reference waveform accordingly.