The target generates a trigger signal. After that trigger, the CW1200 has to generate a precise delay for this signal, and trigger the ChipShouter after that delay.
I couldn’t make this setup work by using the Crowbar GlitchOut of the CW1200 as Trigger for the CS.
If I look at the Trigger Routing Screen of the CW1200, it looks like it’s possible to route the glitch out signal to AUX.
How can this be done in the software?
Or is there a different, better way to generate the trigger signal for the ChipShouter by the CW1200?
The crowbar glitchout “should” work - actually that is what I’m using as a triggering method for 80% of my ChipSHOUTER usage! So could troubleshoot that… although due to the MOSFET in the way with the crowbar it doesn’t go as narrow (or requires some effort in mapping commanded glitch width --> actual width). I assume that is the problem you are seeing (and not that it doesn’t work at all). If you aren’t getting it to work at all let me know, as it should work ‘fairly’ well.
As a quick work-around - are you using the CLKOUT (HS2) right now? You can definitely route a glitch out to that, and if you’ve got a CW1200 it should have come with the breakout board that has the SMA on the HS2. That should “cleanly” connect through as you want…
But on the aux signal - I’ll double check. I know we had some issue w/ the FPGA build, so I think it was removed (I see some of the SMAUX logic commented out - the FPGA code is all in the git repo). The FPGA tools tend to not like when we route these clocks all over the place with muxes. We may end up just needing to offer multiple bitstreams you switch between when you want to use different features, which have more fixed clock routing. This actually isn’t too bad to do, as the bitstreams get reloaded on connect anyway. And I think 99% of the time you’re using the SMAAUX for a specific use given your setup - that is there isn’t a need to switch half-way through your analysis for SMAAUX being the glitch out to SMAUX being the clock input for example.
Hi Colin, thank you very much for your answer. We could resolve our problems in the meantime. We were able to use the glitch out on cw1200. We reversed your youtube video about Bam Bam for that so we could find the proper output settings.
However, the output of Crowbar Glitch is only about ±1V, which is not enough for TrgIn of ChipSHOUTER.
Even after performing with the parameters referring to the Colin’s video here (e.g., glitch parameters such as width, offset and output), the output of Crowbar Glitch did not reach 3.3V.
The following graph shows the observed voltages of the aux output and the crowbar output on an oscilloscope. As this figure shows, the crowbar output does not reach 3.3V and cannot be used as a trigger input.
Thank you for your kind reply. I have not set the chipSHOUTER to an active low trigger.
The graph in my recent post is based on direct observation of the output of Aux and Corwbar Glitch with an oscilloscope. Therefore, I was wondering if there is something wrong with the ChipWhisperer. Is it possible that the output of the Crowbar Glitch does not reach 3.3V according to the specifications?
As said earlier, the ChipWhisperer glitch port is an open drain configuration, meaning it can only connect something to ground, not provide power to it. The active low configuration on the ChipShouter enables a pull up resistor, which will be pulled low by the ChipWhisperer when the glitch is active.
Try disconnecting the ChipWhisperer from the ChipShouter and set the ChipShouter trigger input to active low, high impedance. If you’re getting a fault, then there is an issue with the ChipShouter setup. Otherwise, I’d say there’s an issue with the ChipWhisperer setup.
When I pressed the Pulse button on the ChipSHOUTER, the Pulse LED lit up, so I mistakenly thought it would also light up when driven by an external trigger. The voltage monitor of the ChipSHOUTER showed that the pulse was emitting.