The meaning of glitch width

Hi,

During voltage glitching I am using “Ext Trigger Continuous” for N clock cycles combined with “Enable Only”, which gives the width of one glitch ( = N clock cycles).
My question is, how is this influenced by “Glitch Width (as % of period)”?
I was looking on the diagrams shown in the clock and voltage glitching tutorials, and I would guess that the enable line is activated after the trigger and it is latched with the clock. Therefore as “Glitch Width (as % of period)” only gives the phase for “Shifted #2” on this diagram https://wiki.newae.com/File:Glitchgen-phaseshift.png meaning that it doesn’t play any role in this case, but my experiments show that it has some effect, or it is a random coincidence (well it is glitching, so it can be). I am running more experiments to collect a bigger data set, but I thought I also ask if there is more to it than what is shown on the simple diagrams.

I set it to output to FPGA-HS2 and measured it with an oscilloscope and it seems that with Enable Only, the glitch width is not used. Your pulse width is (1/freq)*(number repeats).

Okay, thanks :wink:
Maybe it should be another topic, but if I set the number of repeats to anything below 10 (@27MHz), then the glitch won’t repeat itself. It might be problematic as I am experiencing successful glitches with lower repeat counts.
What can cause this issue?

Here are two images with repeat count 9

and 10

every other setting was left the same

edit: here are the links in case the embedded images won’t work:
ibb.co/eXXyLH
ibb.co/gMLk0H

Hello,

The glitch “repeat” should work down to 1 without issue. You might be seeing an artifact of the output drive and/or scope measurement.

As a test you can set the width to something reasonably high (~40%) and enable JUST the glitch output on the HS-1 output pin. This should make it more obvious how many glitches are being repeated.

the glitch width is not used

Yes this is by design - the “enable only” just takes into account the # of cycles. It’s designed to give you larger glitches that span multiple cycles (mostly useful for crowbar glitches).

Let me know if the above makes sense!

-Colin

Dear Colin,

I am trying to glitch the power of the target device, using the ‘high power’ mosfet in the crowbar circuit.
The target is also supplied with clock from the chipwhisperer’s HS-2 out pin.

Here is the init script (some target specific parts have been omitted, and marked):

        lstexample = [['Simple Serial', 'NewAE USB (CWLite/CW1200)', 'baud', 115200],
                      ['CW Extra Settings', 'Target IOn Pins', 'Target IO1', 'Serial RXD'],
                      ['CW Extra Settings', 'Target IOn Pins', 'Target IO2', 'GPIO'],
                      ['CW Extra Settings', 'Target IOn Pins', 'Target IO3', 'GPIO'],
                      ['OpenADC', 'Clock Setup', 'Freq Counter Src', 'CLKGEN Output'],
                      ['OpenADC', 'Clock Setup', 'CLKGEN Settings', 'Multiply', 9],
                      ['OpenADC', 'Clock Setup', 'CLKGEN Settings', 'Divide', 32],
                      ['OpenADC', 'Clock Setup', 'CLKGEN Settings', 'Desired Frequency', 27000000.0],
                      ['OpenADC', 'Clock Setup', 'ADC Clock', 'Source', 'CLKGEN x4 via DCM'],
                      ['OpenADC', 'Clock Setup', 'ADC Clock', 'Reset ADC DCM', None],
                      ['OpenADC', 'Clock Setup', 'ADC Clock', 'Phase Adjust', 0],
                      ['OpenADC', 'Trigger Setup', 'Total Samples', 1000],
                      ['OpenADC', 'Trigger Setup', 'Timeout (secs)', 4.0],
                      ['OpenADC', 'Trigger Setup', 'Mode', 'rising edge'],
                      ['OpenADC', 'Gain Setting', 'Mode', 'high'],
                      ['OpenADC', 'Gain Setting', 'Setting', 40],
                      ['CW Extra Settings', 'Target HS IO-Out', 'CLKGEN'],
                      ['Glitch Module', 'Output Mode', 'Enable Only'],
                      ['CW Extra Settings', 'HS-Glitch Out Enable (High Power)', True],
                      ['Glitch Module', 'Glitch Trigger', 'Ext Trigger:Continous'],
                      ['Glitch Module', 'Glitch Offset (as % of period)', 0.0],
                      ['Glitch Module', 'Glitch Width (as % of period)', 0.0],
                      ['Simple Serial', 'Load Key Command', u''],
                      ['Simple Serial', 'Load Input Command', u''],
                      ['Simple Serial', 'Go Command', u''],
                      ['Simple Serial', 'Output Format', u'$GLITCH$'],
                      ['Aux Settings', 'Reset !!! Omitted !!! target via CW-Lite', 'Reset Timing', 'Post-Arm'],
                      ['Glitch Explorer', 'Normal Response', u'"!!! Omitted !!!" in s'],
                      ['Glitch Explorer', 'Successful Response', u'"!!! Omitted !!!" in s'],
                      ['CW Extra Settings', 'Trigger Pins', 'Target IO4 (Trigger Line)', True],
                      ['Glitch Module', 'Clock Source', 'CLKGEN'],
                      ['Glitch Explorer', 'Tuning Parameters', 2],
                      ['Glitch Explorer', 'Tuning Parameter 0', 'Name', u'Ext Trigger Offset'],
                      ['Glitch Explorer', 'Tuning Parameter 0', 'Parameter Path', u"['Glitch Module', 'Ext Trigger Offset']"],
                      ['Glitch Explorer', 'Tuning Parameter 0', 'Data Format', 'Int'],
                      ['Glitch Explorer', 'Tuning Parameter 0', 'Range', (0, 255)],
                      ['Glitch Explorer', 'Tuning Parameter 0', 'Value', 0.0],
                      ['Glitch Explorer', 'Tuning Parameter 0', 'Step', 1.0],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Name', u'Repeat'],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Parameter Path', u"['Glitch Module', 'Repeat']"],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Data Format', 'Int'],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Range', (8, 25)],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Value', 8.0],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Step', 1.0],
                      ['Glitch Explorer', 'Tuning Parameter 1', 'Repeat', 10],
                      
                      # Final step: make DCMs relock in case they are lost
                      ['OpenADC', 'Clock Setup', 'ADC Clock', 'Reset ADC DCM', None],
                      ['Glitch Module', 'Reset DCM', None],
                      ]

The reset script have been also modified as the gui halted because the mosfet randomly stayed open after a few iteration, as well as it only opened at every 2nd iteration.
In chipwhisperer/software/chipwhisperer/capture/auxiliary in Reset_!!! Omitted !!!_target.py in def resetDevice(self):

CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'HS-Glitch Out Enable (High Power)', False])
CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'HS-Glitch Out Enable (High Power)', True])
CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'HS-Glitch Out Enable (High Power)', False])
CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'HS-Glitch Out Enable (High Power)', True])
CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'Target IO3: GPIO', 'High'])
CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'Target IO3: GPIO', 'Low'])
CWCoreAPI.getInstance().setParameter(['CW Extra Settings', 'Target IOn GPIO Mode', 'Target IO3: GPIO', 'High'])

Trigger (glitch module probably captures the trigger, openADC not, but that is not even necessary, so):
In chipwhisperer/software/chipwhisperer/capture/scopes in _OpenADCInterface.py in def capture (self):

    ...
    #return timeout    # original
    return False

Query the connected usb devices with lsusb from python to identify if the target entered into !!! Omitted !!! mode due to successful glitching or not
In chipwhisperer/software/chipwhisperer/capture/ui add to GlitchExplorerDialog.py in addResponse(self, resp):

#-----------------------------------------------------------------------

import subprocess
lsusb = subprocess.check_output('lsusb')
print(lsusb)
normal_response = "!!! Omitted !!!"
successful_response = "!!! Omitted !!!"

if normal_response in lsusb:
    normresult = True
elif successful_response in lsusb:
    succresult = True
#-----------------------------------------------------------------------

Furthermore:
The glitch explorer only accepted 64 bytes of data from the serial terminal. When the simple terminal function is used it reads in everything without restriction. The relevant parts are after the first 64 bytes…
It was a timeout issue combined with an argument indicating the number of bytes to be read set to 64:

GlitchExplorerDialog.py
    class GlitchExplorerDialog
        def addRespones (self, resp)    # this is where the string evaluation happens in Glitch Explorer window. resp was set to 64 by:

CVCaptureGUI.py
    class CWCaptureGUI
        def newTargetData (self, data)    # data is passed to resp above

        def __init__ (self, api):
        ...
            self.api.sigNewInputData.connect (self.newTargetData)
        ...

CWCoreAPI.py
    classCWCoreAPI
        def __init__ (self):
        ...
            self.sigNewInputData = util.Signal()
        ...
        def setTarget (self, driver):
            self.getTarget().newInputData.connect(self.sigNewInputData.emit)
        ...

SimpleSerial.py
    class SimpleSerial
        _name = "Simple Serial"
        ...
        def readOutput(self):
        ...
            if ...
                try: ....
                except ....
                    databytes = 64    # this is where the response length was limited, setting it higher resulted in 127 bytes being read unrelated from the value
                ...
                self.newInputData.emit(self.ser.read(databytes))
                return None    # takes this return
        ...

        def __init__ (self):
            ...
            ser_cons = pluginmanager.getPluginsInDictFromPackage ("chipwhisperer.capture.targets.simpleserial_readers", True, False)
            self.ser = ser_cons [SimpleSerial_ChipWhispererLite._name]
            ...

_base.py
    class SimpleSerialTemplate
        def read (self, num=0 , timeout=250)    # num is resp (64), and timeout resulted in only reading in 127 bytes, no matter of the value of num, I set it to 2000 (too low restarts the target too quick and not all the relevant UART data arrives, too high makes the CW hang and wait in case the target crashed)

Now, how should I try to make it continuously repeat the glitch with the repeat value set to lower than 10?
p.s. Don’t get me wrong, I am not dumping everything on you and expect you to solve it for me, I am telling you it doesn’t work, and just trying to give you enough information so you can reproduce it.