Hello, I have noticed some strange behavior. According to chipshouter documentation. The formula for total pulse length in seconds should be:
repeat * (deadtime/1 000 + pulseLength / 1 000 000 000)
If that is correct then for my settings I should get roughly 0,32s total duration.
20 * (16 / 1 000 + 80 / 1 000 000 000) = 0,3200016
However, I am seeing some strange behavior.
I was getting inconsistent results so I took some meassurements and it looks like the pulse is still going even though it should have ended long time ago. The Y axis have amount of bitflips, X axis is time of the meassurement in seconds (0,05s intervals) and the dot line is expected end of the pulse.
I would expect to get consistent result after the pulse ends → right after (or very close to) the dot line and not few hundred ms after.
How did I obtain the data:
- fill ballistic gell with 1s or 0s
- pulse
- sleep(n) where n is from <0;10> in 0.05 intervals (e.g. 0, 0.05, 0.1,…)
- do read and analyse data
I did this 3 times per n for ones and 3 times per n for zeros and always used mean of the results.
Is there any way to be able to calculate the amount of sleep needed for the pulse to finish per configuration?
It’s been a while since I looked at the ChipShouter’s code, but there’s a few things that might be in play here:
- The pulse timing isn’t done in hardware on the ChipShouter, it’s all done in software on a microcontroller, so that formula is more of a minimum than what you’re typically going to see. Each parameter (repeat, deadtime, pulseLength) will have an additional fixed and variable delay associated with it, with the fixed delay on the pulseLength probably contributing the most in your case. You should see something closer to what you’d expect with a larger pulseLength.
- You’re affecting voltage/timing inside the SRAM, which causes some instability inside the chip. This may go on for a substantial amount time after the glitch ends, so that may be a contributing factor as well.
Alex
Is there a way for me to estimate the wait time for different settings? I am asking mostly about the first case. I am assuming in the 2nd case the instability should take more or less the same time regardless of the settings, I might be wrong though.
I can always set the sleep time to some higher number, like 5 seconds, but the board sweep is already taking approximately 14 hours with 2s fixed sleep time. I am afraid that in some cases the instability will remain even after 2 seconds have passed.
It’d be pretty hard to estimate just from the code. I’d recommend using an oscilloscope with the current measurement output to see what the actual inserted pulse looks like and going from there.
