Assembly level triggering



I would like to know if there is any way to give an assembly level triggering instruction for clock glitching in Chipwhisperer. If yes, how to do that?



Do you mean on a specific instruction? The ChipWhisperer-Lite doesn’t have the ‘sum of absolute difference’ (SAD) trigger which can be used to trigger on specific power signatures.

Otherwise it still need some sort of trigger signal…


Thank you very much for your response.

Actually, I am trying to do instruction level clock glitch attack using chipwhisperer -lite board, for which I am converting the main C code to assembly level code and then compiling the assembly level code to HEX form, so that I can download it into the target device (XMEGA) and then attack it (using capture software).
I would like to study the attack by providing glitch at different instructions, for which I guess would need to change the position of trigger_high() and trigger_low() functions accordingly. But I do not know how to do this in assembly language. Can you please help me on this or provide any suggestions?



Ah sure thing - that is an easy task! Basically you just need to set/clear the IO pin using assembly code. I actually haven’t done XMEGA programming in assembly though, so you might ask over on instead… the question is how to set/clear PORTA basically.

You can open the listing file (.lss) for the compiled C code to see the assembly level code:

 3fc:	81 e0       	ldi	r24, 0x01	; 1
 3fe:	e0 e0       	ldi	r30, 0x00	; 0
 400:	f6 e0       	ldi	r31, 0x06	; 6
 402:	81 83       	std	Z+1, r24	; 0x01

So to first configure the port, do the following:

ldi	r24, 0x01	; 1
ldi	r30, 0x00	; 0
ldi	r31, 0x06	; 6
std	Z+1, r24	; 0x01

The system is using the following code to set the trigger:

eor	r13, r13
inc	r13
movw	r30, r14
std	Z+5, r13	; 0x05

And to clear the trigger:

eor	r13, r13
inc	r13
movw	r30, r14
std	Z+6, r13	; 0x06

This assumes you haven’t touched the values in R30/R31 (Z-Register). Note the eor r13,r13; inc r13; is just setting r13 to 0x01. So you only need to run those two lines once if you don’t touch r13 anywhere.

You can make this faster by using virtual address space (see, so if you don’t want as many instructions that is an option.

Note it’s also possible to mix C & assembly too. Se efor example: … 0XMega.pdf

Good luck!



Thank you very much for your immediate response.
I guess what you have suggest would work good for me. I will try it out and let you if I need any more help regarding chipwhisperer-lite.
Thank you once again. :smiley:


Sounds good - if you have any issues let me know. I haven’t done ASM programming so if you do need help please upload your example code too (either for avr-as/avr-gcc or with Atmel Studio), as I don’t have anything that I can easily compile here to test my pin set/clear code.


Hi Coflynn!

Can you give me the i/o mapping for the registers (X, Y and Z) of Xmega with the FPGA in ChipWhisperer-lite device?
Hoping to get a reply soon.

Thank you.



Sorry which I/O mapping? There isn’t any direct connection between the external memory bus of the XMEGA & the FPGA device if that is what you mean… everything must be done via firmware loaded on the XMEGA.



Hi Colin,

Thank you for your immediate response.
If you consider the assembly code for tigger_high() and trigger_low(), that you have suggested in our previous conversations, the command "std Z+5, r13 " is used to set the trigger and the command "std Z+6, r13 " is used to clear the trigger.
So, I would like to know:

  1. What is the relation between this Z-register and the other registers?
  2. What and how does this indicate the ChipWhisperer-lite to either set or clear the trigger?
  3. Which register or port of the ChipWhiperer-lite is actually this Z-register mapped to?

Thank you.



Ah gotcha! To answer your question:

  1. The Z-Register is part of the XMEGA registers. See page 11 of
  2. The triggers are just physical port pins - in this case if you set PORTA.0 it is the trigger. You must clear that pin at some point before the next run (I clear it after crypto normally, since you can tell how long the operations took).
  3. The Z-Register is only part of the XMEGA device… we just use the set/clear of the physical port pin as a method of triggering the CW-Lite.

Hopefully this helps!




Thank you very much Colin. You have cleared off my doubts. I hope I can ask you if I need any such help in the future.
Thank you once again! :smiley:


Hi Colin,

Can you explain the difference between the External:Single-Shot and External-Continuous Glitch trigger types given in the glitch module of ChipWhisperer Capture software?


Ah sorry that’s not too well documented… basically:

  1. Single-shot requires the scope to be armed. the system only generates a glitch if (a) the scope is armed and (b) the trigger conditions are met (i.e., a rising edge).

  2. The continuous will generate the glitch anytime the trigger conditions are met. It doesn’t require the scope to be armed, so you can generate continuous glitches if for example your target system keeps resetting.


Hi Colin,

Thank you very much for your explanation regarding single-shot and continuous glitch trigger types. I was thinking that a single shot glitch trigger would insert clock glitch in only one immediate clock cycle after the trigger_high() is called, whereas, ext trigger: continuous would glitch all the clock cycles that follows the trigger_high() call till the trigger_low() is called.

By the way, is there a way to control how may clock cycles are glitched after the trigger? If there is a way to do so, please tell me how to do it. Please also let me know currently how many clock cycles are inserted with glitch after trigger_high() is called, is it only one or randomly many?

Awaiting your reply, thank you.



There is a value called “cycles to glitch” or similar (sorry away from desk right now so don’t have hardware), but you should be able to set the number of cycles to glitch!

And the “continous” will glitch while the trigger is high, that is also true. Basically the “single-shot” only generates a single trigger glitch…

Hmm maybe I should write this all down, give me another day to try and update the documentation with all these details. As it’s something that is missing!



Hi Colin,

In the Capture software, there is an option to change the external trigger offset under the glitch module. But the unit is not mentioned in the documentation.
Please could you let me know the measure of ext. trigger offset, i.e., if it is measured in seconds or by number of clock cycles?
Also please could you provide your email id so that it would be much easier for me to attach files and discuss about it?



The unit is clock cycles of the glitch clock - so depending how you setup that will affect what the offset runs in.

I only provide support via this forum, otherwise my email gets overloaded sorry!