Few questions about ChipShouter

Hello I am recently trying to use the ChipShouter and have some questions about the device.

1.Are there any tutorials on how to use it? I got familiar with the python/serial scripts but I heard that triggering over the hardware input is better. I have the ChipWhisperer PRO and found out it can kind of trigger the CWShouter, but how do I control the pulse over the hardware trigger and how do I do that over the CWPRO in general?

2.I was testing out the patterns and different setup together with my oscilloscope and found following out, that the pulse isnt always “strong”, is that a feature or a bug?

For 500v and pattern
cs.pat_wave = ‘111111110011110011110’
I got following waveform measured

Why are the last two pulses way weaker?


Here I set the pulse width to 400 and voltage to 500, it indeed goes over 400ns but only 160ns are “strong” and “measured”, why does this happen?

3.Is there a way to make the deadtime shorter? 1ms is a lot of time

4.How exactly does the hardware trigger work? Does it simply shoot the saved pulse on a trigger signal? What are the advantages of using it compared to simply using the python script and triggering over the serial?

5.Can ChipWhisperer read ChipShouter pulses, or is it a must to use an external oscilloscope?


The easiest way to trigger via the Pro at the moment is to use the ChipWhisperer’s voltage glitch output. Set the ChipSHOUTER to active low, high impedance, which will activate a pull up resistor on the trigger input. This setup is covered on page 26 of the ChipSHOUTER manual.

I’m currently working on getting the Pro’s aux output working as well, which will allow you to use that to trigger the ChipSHOUTER.

I don’t believe we have any full tutorials for the ChipSHOUTER. The focus there is moreso on demos with the included targets. If you want, you could replace the voltage glitching in ChipWhisperer tutorials with the ChipSHOUTER by swapping the glitch output from the target to the CS’s trigger input.

You’re running into the limitations of the device here - long/rapid pulses at strong settings will quickly saturate the probe, drain the cap bank, etc.

I’d recommend lowering the voltage and using shorter pulses. Different coils might also work better here.

I’m pretty sure this comes from the tick of the microcontroller’s timer which is used for a bunch of things. Unfortunately, it doesn’t make sense to make this any shorter: a very quick timer wouldn’t work well for all of the longer times in the CS, and interrupting all the time to increment timers, check timeouts, etc. would have a detrimental effect on performance in other areas.

A hardware trigger can be preferred because there’s very little latency/jitter compared to a software trigger. With the latter, you’re looking at jitter in the order of 10’s to 100’s of ms, which can be an issue if you’re trying to glitch at a precise point in time. The downside is that you lose the pulse configuration, through you can replicate this to an extent on the trigger signal.

As you can see from the device block diagram (https://raw.githubusercontent.com/newaetech/ChipSHOUTER/master/documentation/ChipSHOUTER%20User%20Manual.pdf page 15), this is just XOR’d with the ChipSHOUTER’s microcontroller trigger. All the pulse settings are done by the microcontroller, so they won’t have any effect on the hardware triggered pulse.

There’s also a full schematic, which you might also find useful: ChipSHOUTER/NPCA-CW520-ChipSHOUTER-07_Schematic.pdf at master · newaetech/ChipSHOUTER · GitHub

You’ll need to use an oscilloscope. I’m not sure if it’ll kill the ChipWhisperer, but the voltage swings are well beyond the maximums for the amp/anything else on the board, so the potential for damage is certainly there.


What voltage do you recommend? I tried 300V and got the same result, but the initial waveform was just smaller (the other ones were at the same strength as at 500V). Using the 4mm CW probe.

How do I configure the voltage and pulse width then? Cant the setup be saved in eeprom?

In that case, you’ve probably fully discharged the capacitor bank. Not really much you can do here.

The voltage will be the same as what you’ve set. That’s just what the capacitor bank is charged to and doesn’t have anything to do with the pulse configuration.

For the pulse settings, it’s not a matter of storing them. The pulse settings are controlled by the ChipSHOUTER’s microcontroller. The hardware trigger bypasses the microcontroller entirely. That, means that if you replicate what the microcontroller is doing on its trigger pin with the hardware trigger pin, you should achieve similar results. You’ll want to the use the active high 50-ohm hardware trigger for this mode. With the ChipWhisperer, currently the HS2 signal via the Advanced Breakout Board is your best bet. The AUX output should also work for this, once it’s ready.


What is the default pulse width when I use the hardware trigger? Or does the pulse last as long as the trigger is set?

Could you tell me how to simply create triggers on the glitch output without going through all the tutorials?

The pulse lasts as long as the trigger is set.

If you want to quickly setup a glitch on ChipWhisperer, you can call scope.vglitch_setup('lp'). From there, you can call scope.arm(), which arms the glitch, which will fire on a rising edge of the ChipWhisperer’s TIO4 pin. scope.capture() blocks on completion of the glitch or a timeout.

vglitch_setup() is a newer method, so if you don’t have it, here’s the source code so that you can replicate what it’s doing: chipwhisperer/OpenADC.py at develop · newaetech/chipwhisperer · GitHub

Some settings you might find useful:

  • scope.glitch.output = 'enable_only' keeps the glitch going for a full CW clock cycle. I recommend this setting for the trigger
  • scope.glitch.repeat controls how many clock cycles the glitch is active for.
  • scope.glitch.ext_offset controls the offset of the glitch in clock cycles from the trigger


does it mean I have to do some extra wiring of the CWpro on the 16th pin? Like connecting this pin to my rising edge signal? or can this pin be triggered via python somehow? or is the trigger_high() function sufficient?

cant I just send a high signal on the hardware trigger of ChipShouter without changing the hwtrig mode? Im wondering if the additional layers to create the glitch wont add unnecessary delay to the device? From my understanding we have to configure a target to send a trigger signal to the ChipWhisperer pin16 in order for it to create a glitch and send a signal to the Shouter so it can generate the pulse…

Just to clarify my understanding and my problem:

I have the CW308, CWPRO and ChipShouter.

I have a target which does an operation after some time the reset is pressed. I want to disrupt this operation by injecting a fault. I read that using the hardware trigger causes less delay so the pulse can be more precise.

I can set a pin on my target which will cause a trigger signal when the reset is pressed. I then have to delay this signal a little bit so that it doesnt cause a pulse on the reset, but after few microseconds.

The question here is, how do I add a delay to the trigger signal and then forward the delayed trigger to the CW, so that it can glitch and pull down on the CHipShouter for it to cause the pulse?

My idea was to send the reset trigger signal from my target to the CW308 target board, where an STM is running a program that delays that signal(to hit the right timing) and sends the trigger over the GPIO4 or PIN16 to the CWPRO. The CWPRO then modifies this signal in order to create a trigger signal with enough width or a special pattern(send 3 small triggers or a longer trigger to increase pulse width). Then it forwards the signal via the glitching output to the ChipShouter, which is set to hwtrigmode 0.

Is this a little bit too overthought? Wont this setup cause too much delay in between the devices, if it will actually work? What would be a better solution to this problem?

Do I actually need the CWPRO to trigger the Shouter over hardware pin? Cant I just send a trigger high on it and ignore the hw_trigmode 0?

There’s no need to delay before you get to the ChipWhisperer, it can insert a delay itself (scope.glitch.ext_offset). In fact, if you want, you can trigger directly on the rising edge of the nRST pin (scope.trigger.triggers = 'nrst').

Yeah, this sounds about right, except I’d recommend delaying using the ChipWhisperer. Also, if you want to try the three smaller triggers, you’ll need to use either the aux out or HS2 pins. The recovery time after pulling the trigger low is too long with the glitch port because you’re relying on the pullup to drive the pin high. The AUX output is now available on the latest CW commit: Scope API — ChipWhisperer 5.6.1 documentation (you’ll want the 'glitch' setting).

There will always be a small (a few clock cycles, usually in the 10’s of nanoseconds) constant minimum delay between the trigger and the glitch, but you’d need a pretty specific application for this to be an issue. If you’re looking to delay at all, then this won’t affect you at all.

Technically this is possible, but I don’t recommend it. If you do this, you lose the ability to delay at all, or configure the glitch in software. You could also run into the situation where your target crashes and it never pulls the trigger low again, meaning the CS is constantly trying to glitch. The ChipSHOUTER should handle this situation fine (very low safety risk or risk of damage), but it’s still best avoided.


Which nRST pin do you mean? The one on the CW Target board or the pin5 of CWPRO, if yes, why not use the Pin16??

Is there actually a way to skip the UFO Target board in this setup and directly lead the trigger to the CW PRO, then delay it there and forward to the chipshouter? Like using the AUX of CWPRO to capture the trigger signal, then delay it with CWPRO and forward it through GLITCH output into CS?

If you’re using the nRST pin to reset the target and the operation you’re interested in has a constant delay from reset, you can use that instead of a dedicated trigger pin.

I’m a little confused by your hardware setup. Are you using a ChipWhisperer target, or a third party one?


yes, the target is 3rd party, on the reset it sends a short trigger signal, I have to delay that signal to hit the right point with the cs

Ah yeah, in that case you can connect directly to the 20-pin connector and bypass the CW308, unless you’re using something on the CW308 (xtal to clock, voltage regulators, etc.)