Changes

<olli> <p> Run the aux reset script for the appropriate target. The avr, stm32f and xmega targets use the <code>aux_reset_cw1173.py</code>. '''This scripts needs to be modified for the specific target'''. Uncomment the line for your target and comment out the lines for the other targets. The timing of the reset can also be changed, the comments explain the pros and cons of each. The reset after arm usually works better and needs less setup, but this depends on the target.</p> <syntaxhighlight lang=python>"""Set up resets via CW1173Contains a few adjustable lines to switch between XMEGA/AVR/STM32F and change resettiming (relative to scope arm)"""

<li>Switch to the ''Aux Settings'' tab# GUI compatibilitytry: aux_list = self. Depending on your module you will see different settings here, for example the ChipWhisperer-Lite lets you select aux_listexcept NameError: pass # Delay between AVR arming and resetting, in msdelay_ms = 1000 # Reset XMEGA targets. This normally defaults to the &quot;XMEGA&quot; deviceResetter = ResetCW1173(pin='pdic', so be sure to switch this to the &quot;AVR&quot; delay_ms=delay_ms)# Reset STM32Fx device if using the NOTDuino or Multi-Target boards!</li><li>Switch to the #Resetter = ResetCW1173(pin='nrst'Target Settings, delay_ms=delay_ms)# Reset AVR#Resetter = ResetCW1173(pin='nrst' tab, and delay_ms=delay_ms) # Reset before arming# avoids possibility of false triggers# need delay in target firmware to avoid race condition#aux_list.register(Resetter.resetThenDelay, "before_trace") # Reset after arming# scope can catch entire reset# avoids race condition# target reset can cause false triggers (usually not an issue)aux_list.register(Resetter.delayThenReset, "after_arm")  </lisyntaxhighlight></ol>

<li>Switch to the ''Scope Settings'' tab.</li> <li>Switch the ''ADC Clock Source'' as being ''CLKGEN x4''.</li> <li>Press ''Reset ADC DCM'', confirm the frequency is 29.5 MHz as expected.</li> <li>Switch the ''Trigger Setup'' --&gt; ''Mode'' to be ''Rising Edge''</li> <li>Switch the ''Trigger Setup'' --&gt; ''Total Samples'' to be ''1000''</li> <li>Switch the ''Gain Setting'' --&gt; ''Setting'' to be ''40''. You might need to adjust this for different hardware.</li> <li> <p>Press ''Capture 1'', confirm some waveform is displayed. For example with the NOTDuino Target on the ChipWhisperer-Lite, the waveform looks like this:</p> <p>[[File:waveform-notduino-normal.png|image]]</p> </li> <li>If this does't work: check the trigger in use is the ''Target IO4'' pin.</li> <li> <p>Play around a bit with the glitch width, offset, and repeat. You should see different effects in the power consumption traces. For example the following shows a narrow (15% pulse width) glitch being inserted:</p> <p>[[File:waveform-notduino-glitch1.png|image]]</p> </li></ol>

<ol style="list-style-type: decimal;"> <li>Switch to the ''Target Settings'' tab, and set the ''Output Format'' to <code>$GLITCH$</code>.</li> <li> <p>Open the ''Glitch Explorer'', and hit ''Capture 1'' a few times. Confirm this populates the table with various examples.</p> <p>[[File:ge-normal.png|image]]</p> </li> <li> <p>We need to setup the ''Normal Response'' and ''Successful Response''. Note in this example the normal response has a little random noise we want to ignore, but we want to capture when the device resets after the glitch and sends the &quot;hello&quot; message twice. We could accomplish this with the following bit of Python code:</p> <pre>s.endswith(&quot;hello\nA&quot;) and (len(s) &lt; 12)</pre> <p>This looks for both the ending without glitch, and the length of the string isn't too long. In the case of the successful glitch, we just want to see if &quot;1234&quot; is printed. This can be accomplished in Python with:</p> <pre>&quot;1234&quot; in s</pre> <p>You can always experiment using the ''Python Console'' to see how your potential systems work. For example here is checking that the first line works:</p> <pre>&gt;&gt;&gt; s = &quot;\x1ahello\nA&quot;

<p>Finally, configure the Glitch Explorer:</p>