Trouble glitching third-party target

Hello, I am trying to glitch a EFR32FG23B. The chip is connected to a Silicon Labs dev board. In short, I have trouble with performing the crowbar FI with the CW-Lite, and are looking for pointers as to how I can solve this problem. I am a new user, so I couldn’t embed more than one picture, sorry about that. Pictures I refer to in the post can be found here: NewAE forum post — ImgBB

I am running a double for loop, which in total counts up to 100 000.

I have been using the enable_only glitch mode. I am fairly positive that my setup is mostly correct, as I have been able to locate the “reset border”. This can be seen on the parameter map below. Target ran on 7Mhz, while CW ran on 112MHz.

  • Red - FI caused a device reset
  • Yellow - Trigger timeout, sends reset signal to target(have a question regarding this at the bottom)
  • Blue - Normal operation
    lp_hp_7mhz_112mhz_decouple_cap

Some traces of the injected glitch:

  • Blue - Reset signal on target
  • Yellow - Trigger
  • Green - Glitch/digital core

See picture named: 7mhz_56mhz_1_repeat_edit.png
See picture named: 7mhz_56mhz_1_repeat_zoomed_out_edit.png

The traces above was taken with a target frequency of 7MHz. CW-Lite with 56MHz. And a glitch-setting repeat of 1. This should mean that the glitch should last for about 18ns, which can be seen by the cursors above.

See picture named: 7mhz_56mhz_4_repeat_edit.png

The trace above had a repeat of 4, so should last about 18ns*4=72ns.

The EFR32FG23B chip has fault injection countermeasures, but I am fairly positive that all of these are off/have a “do nothing” behavior by default.

So I am a bit lost. This should be a fairly easy glitch to achieve, but I am not getting any successful glitches. I have tried running glitch campaigns in the are close to the “reset border”. Any pointers here as to what I can do/explore?

Then I have a question for the timeouts. Whenever I get a timeout, CW gives me the following error:

(ChipWhisperer Scope ERROR|File OpenADC.py:781) Received fewer points than expected: 4620 vs 5000.

The number which above is 4620 varies, but its always between 4500 and 5000.
On the figure below you can see that there is a timeout. The point where the blue signal goes low is my code sending the reset signal, which is where a timeout occurs. While every spike of the blue line is a reset caused by the device.

See picture named: 7mhz_112mhz_manual_reset_edit.png

So any ideas as to what could be the connection between this scope error and the trigger timeouts that are occurring?

Snippet of the code that handles timeout events:

ret = scope.capture()
if ret:
            print('Timeout - no trigger')
            gc.add("timeout", (scope.glitch.ext_offset, scope.glitch.repeat))
            reset_target()

This ended up being quite a long post, thanks if anyone find the time to share some thoughts:)

I took a quick look at the EFR’s reference manual, but I didn’t see that in there. Do you have a link to any documentation regarding the fault countermeasures?

You can try bumping up the frequency even higher to gain extra precision on the glitch. For example, when running our LPC glitch demo, we usually run at 200MHz.

Something this might be issues with the ADC/ADC part of the FPGA, since that’s only rated to 105MS/s. You may want to only rely on output back from the target to determine success/reset/normal instead of the trigger.

Alex

Sorry for the long delay in my response. I ended up achieving a stable glitch setup. The biggest contributing factor for my new successful setup was by changing the value of the decouple capacitor.

This document shows on page 8-9 the default operation for different countermeasures, where most of them are off by default:

1 Like