Issue with Trigger Placement on Husky

Embedded Security Side Channel Power Analysis
1

Hi,
I’m encountering a problem with the Husky. I am trying to capture the following operation:

for (j = 0; j < 15; j++) {
    v->vec[0].coeffs[j] *= 1 - 2 * b;
    }

When I put the trigger calls inside the loop, everything works well: we observe 15 spikes and the data are usable for performing an attack :

for (j = 0; j < 15; j++) {
    trigger_high();
    v->vec[0].coeffs[j] *= 1 - 2 * b;
    trigger_low();
    }

However, when I move the trigger calls outside the loop to simulate more realistic capture conditions, I can’t interpret anything from the trace. I’ve tried declaring the variables as volatile, but it didn’t make any difference:

trigger_high();
for (j = 0; j < 15; j++) {
    v->vec[0].coeffs[j] *= 1 - 2 * b;
    }
trigger_low();

trigger_a-lexterieur
trigger_a-lexterieur1000×750 20.3 KB

Interestingly, when I run the exact same code on a ChipWhisperer Lite, everything works as expected, regardless of whether the trigger is placed inside or outside the loop. After comparing the .hex files, we noticed that the trigger_high() and trigger_low() functions are never called in the build targeting the Husky.

Do you have any idea why this is happening? Could the compiler be optimizing away the trigger functions when they’re outside the loop?

Thanks in advance for your help!

2

Here is the trace with trigger calls inside the loop for comparison:

trigger_interieur
trigger_interieur1000×750 23.2 KB

3

That is strange, however from what you’ve said I don’t think it’s true that the trigger calls were removed. trigger_high() is what raises the GPIO4 line which in turn tells Husky to capture the power trace. If GPIO4 is not raised, then you would get this message when you attempt to capture a power trace.
Timeout in OpenADC capture(), no trigger seen! Trigger forced, data is invalid

It sounds like the compiler is doing some optimizations which are (a) making it harder for you to recognize the trigger calls, and (b) dramatically changing the nature of the compiled code. This is what compilers do, for better or worse!

Look at scope.adc.trig_count after your capture. This reports how many ADC clock cycles the trigger line was seen high for; it should give you some hints about what’s happening.