Some considerations / questions about STM32F103C8 target board

These days, I’m experimenting with the various functions of the Chipwhisperer lite using a BluePill STM32F103C8 as a target board. I purposely wanted to use a real board to be able to deal with real problems. I must say that I am a bit demoralized, I tried to use PicoEMP to generate EMP faults but without success, I then tried to use clock glitch and also in this case no result, finally I tried power fault injection (LP, HP and LP + HP) and even in this case no results (I also removed all the capacitors present in the board to remove any possible doubt). I have created a simple c code that does nothing but count and print the various results on the screen but strangely the board seems to be immune to all attempts at attack. Using a RIGOL MSO5074 I verified that the settings made on the Chipwhisperer were correct so I am sure that the various attacks were performed as I expected.
I have attached a screenshot of a power glitch, the board is without capacitors, the strange thinks are the 15V measured after any glitch. Is it normal as behavior ? Is also normal that glitch is generated after 8 clock cycles from trigger (ext_offset on all tests is set to 0) ?

The following is the C code in the target board. With any attack i,n,j,k are not affected!
Anyone have any ideas or suggestions? Is there something I’m doing wrong?

   digitalWrite(LED_BUILTIN, ON);     // Turn the LED ON
    digitalWrite(PC14, HIGH);          // Io for extrnal trigger

    k = 0;

    for (i=0; i<1000; i++)
        for(j=0; j<1000; j++)

    digitalWrite(PC14, LOW);
    SerialUSB.printf("%d] I=%d J=%d K=%d\n", n, i, j, k);
    digitalWrite(LED_BUILTIN, OFF);

The following is the python code of Voltage glitching

import chipwhisperer as cw
import time

scope = cw.scope(scope_type=cw.scopes.OpenADC)
print("Firmware version : " + str(scope.fw_version['major']) + "." + str(scope.fw_version['minor']))
print("Serial number    : " + bytes.fromhex('ASCII')) = False = False

scope.adc.basic_mode = "rising_edge" = "clkgen"  # output glitch_out on the clock line

scope.clock.clkgen_freq = 8E6
scope.glitch.clk_src = "clkgen"
scope.glitch.trigger_src = "ext_continuous"
scope.glitch.output = "glitch_only"

scope.glitch.offset = 1
scope.glitch.width = 15
scope.glitch.repeat = 5
scope.glitch.ext_offset = 0

scope.trigger.triggers = "TIO4"


input("Press Enter to continue...") = True = True

input("Press Enter to continue...") = False = False



Are you only trying with an ext offset of 0? Even with the 8 cycle delay, you’re probably going to hit inside the digitalWrite function since it has to do things like pop all the register values off the stack, pop the LR back into PC, etc. You’ve got millions of operations to glitch here, so don’t feel the need to precisely time this. Also, just to make sure, are i, j, k, and n volatile here? If not, the compiler is just going to do all those add operations during compilation and replace that code with constants.

Regarding the voltage spikes, that is fairly normal due to inductance/capacitance in the overall glitch circuit. What are you using for a shunt resistor? Upping the value a bit should reduce ringing.


All variables are volatile, in other tests I have set ext_offset scanning from 0 to 100000 with 100 of step, so scanning a lot of the full test period, but no faults.

What about the shunt resistor? That will have a large effect on glitching.

I don’t have shunt resistor, isn’t it only for measurement? Why shunt resistot is important for glitch?

The shunt resistor is important because it reduces the current pulled when glitching, meaning you’ll get less ringing.

1 Like

ok, I understand, but is not so easy to insert shunt in a real circuit.
Making other tests I have successfully glitched the board with
scope.glitch.trigger_src = “ext_continuous”
In this way I have a continuous glitch on all the clock period for the number of period I want.