Precise GPIO pulses

Hey!

I’m trying to find a way to get a GPIO (eg. TIO4) to be pulled low for a fairly precise amount of time. I am currently just doing:

scope.io.tio4 = False
# time.sleep(some_value)
scope.io.tio4 = True

This results in roughly 1.5 - 2ms pulse without the sleep, which makes sense I guess, it needs to send a message to CW for each of those lines.

Can anybody think of a better way?


Background

I’m trying to reboot a victim chip by switching its VDD off using a MAX4619. The reason is the code I am trying glitch is only reachable once after POR (Power-On Reset) and there isn’t another way to achieve POR on this device (to my knowledge). RESET pin does not get me to that state.
Turning the VDD off for a fairly variable time of 1.5 - 2ms results in the boot process shift by tens of microseconds or more, which obviously messes with my timing/triggering.

I did already verify I can achieve a mostly stable timing by switching its VDD to GND using MAX4619 for a set/stable amount of time (eg. 5us, or almost any other time as long as it is the same every time) using a random FPGA dev kit.

I thought having a similar feature in the CW ecosystem would be nice.

Do people also run into weird situations like this? Is this a feature that makes sense to spend time on?
I’d try to implement/contribute it if so.

Maybe someone can think of a better way that is easier to implement on CW.

The state of the GPIO pins can only be controlled from software so you won’t be able to get precise timings from those.

Is there a reason you can’t use ChipWhisperer’s glitch module? This is precisely what it’s designed for.

Jean-Pierre

The problem with that is that I need to reset the chip and then glitch shortly after that, so if I use glitch module to do the reset then I cannot use it to do the glitching as the reset is the trigger for the glitch.
Maybe I am overthinking this and having like a CW Nano or some other board doing the reset would be easier.
I just thought it might be handy to have it all in one, perhaps try to extend the FPGA code to allow for high/low GPIO for X number of FPGA cycles or something like that.

You can do this by driving the target reset using scope.io.nrst, and then use nrst as the scope trigger, which is in turn set to be the glitch module trigger. Use scope.glitch.ext_offset to set the number of clock cycles between reset and glitch.

Jean-Pierre

Would it be possible to connect the Vdd pin to TIO4, if that’s not already your setup?

If that won’t work, all the communication from Python to the FPGA goes through the SAM3U, so it should be possible to replicate your Python commands in the SAM3U to avoid the USB and OS latency/variance. You may or may not find this easier than modifying the FPGA to do what you want.

Alex