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

Sorry guys, life happened and I had to put this project on a side for a while. Here’s an update if somebody runs into the same problem.

To hopefully explain the situation better - I do have the Vdd of the target on TIO4 (switched through MAX4619). The problem is when I do scope.io.tio4 = False and then scope.io.tio4 = True the exact time the target chip stays without power varies by +/- ~0.5ms each run. Once Vdd is back the chip starts waking up again and one of the things it does is waiting for its internal RC to stabilize (there is no way to use any external RC during boot-up). The RC stabilization time seems to be directly proportionate to the time the chip remained without power.

Therefore a varying time without power (obviously) causes everything to shift in time. As the glitch point is (shortly) after the RC stabilization, really the only way to make sure the time since “Vdd is back” to my glitch stays constant is to make sure the Vdd is cut for the very same amount of time each run. This in turn makes the RC stabilization time the same (+/- few ns). Unfortunately there really isn’t any other trigger point that would make this more stable (that I could find) and as mentioned before, this case is only glitchable the very first time after power-up, resetting the target by pulling RST doesn’t reset its debugger and it keeps the locked state.

All the above-mentioned are my observations using a very kludgy setup involving another FPGA to time everything as described above.

I think the whole thing can be solved in a simpler way - using something like LTC6993 - Monostable
Pulse Generator (One Shot)
. That way I can generate pulses using any GPIO pin and not worry too much about the exact pulse lengths generated by the setting scope.io.tioX to True/False.

I am sure this is totally implementable on ChipWhisperer’s FPGA but I’ll be honest - after a few hours digging through the python/sam3u/fpga sources I only gathered a basic understanding of the protocol setting the GPIOs, so I gave up :see_no_evil: This seems to not be a common scenario I guess, so not sure it is worth implementing it, opinions?

Just thought I’d post an update if somebody ran into a similar case.